Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-03.txt
Denis <denis.ietf@free.fr> Mon, 11 September 2017 11:19 UTC
Return-Path: <denis.ietf@free.fr>
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 DF5DC133031 for <oauth@ietfa.amsl.com>; Mon, 11 Sep 2017 04:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.617
X-Spam-Level:
X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=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 zD8rja8928MC for <oauth@ietfa.amsl.com>; Mon, 11 Sep 2017 04:19:30 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F7D133023 for <oauth@ietf.org>; Mon, 11 Sep 2017 04:19:29 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id AA5E1780373 for <oauth@ietf.org>; Mon, 11 Sep 2017 13:19:27 +0200 (CEST)
To: oauth@ietf.org
References: <150506417592.8167.6075316607963277976@ietfa.amsl.com> <E6B4D3CE-F1D1-4915-BBD1-1F981A1DF63D@lodderstedt.net>
From: Denis <denis.ietf@free.fr>
Message-ID: <725ec2e8-1021-d5be-cfff-a3c1a2b90aab@free.fr>
Date: Mon, 11 Sep 2017 13:19:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <E6B4D3CE-F1D1-4915-BBD1-1F981A1DF63D@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------35CF7DB48BA26DEF1B7C3532"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/FpQUenWGnP0jJfQQ6APHciga5eM>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 11 Sep 2017 11:19:33 -0000
Hi Torsten, Hereafter is my feedback. There are related to two separate concerns : a) the Alice and Bob Collusion attack" (ABC attack), and b) privacy issues with the audience parameter. *Alice and Bob Collusion attack" (ABC attack)* The text states in section 4.4.1.2 : A typical flow looks like this: 1.The authorization server associates data with the access token, which bind this particular token to a certain client. The binding can utilize the client identity, but in most cases the AS utilizes key material (or data derived from the key material) known to the client. Replace with: 1.The authorization server binds a particular token, either to a public key where the demonstration of the knowledge of the corresponding private key will prove possession of the token, or to an unambiguous well-known identity of the client. The last sentence of section 4.4.1.2 is : "This document therefore recommends implementors to consider one of TLS-based approaches wherever possible". Replace this sentence with the following: However, the binding of a public key to a particular token is unable to counter a collusion attack between two clients, like Bob and Alice that may perform an "Alice and Bob Collusion attack" (ABC attack).Even when private keys are protected by secure elements, a client willing to collaborate with another client will be able to perform all the cryptographic computations needed by the other client.This is a concern as soon as an access token does not contain an unambiguous well-known identity of the client, since the other client would take advantage of one or more personal attributes (e.g. over 18) of the first client without that first client being identified. In order to address that case, clients shall use secure elements that have additional functional and security properties and Authorisation Servers shall make sure that secure elements with such properties are being used by clients requesting tokens. At the moment, none of the OAuth RFCs describes such a technique, but a presentation was made at the OAuth workshop in Zürich in July 2017 where two techniques were described. See: https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf The binding of an unambiguous well-known identity of the client to a particular token fully identifies the client and thus the concern is to prevent the stealing of the token by an external attacker.In that case, this document recommends implementors to consider one of TLS-based approaches. *Privacy issues with the audience parameter* The text states in section 4.4.1.3 states: The audience can basically be expressed using logical names or physical addresses (like URLs). Change it into: _Currently,_ the audience can basically be expressed using logical names or physical addresses (like URLs). The text states in section 4.4.1.3 states: Instead of the URL, it is also possible to utilize the fingerprint of the resource server’s X.509 certificate as audience value. This variant would also allow to detect an attempt to spoof the legit resource server’s URL by using a valid TLS certificate obtained from a different CA.It might also be considered a privacy benefit to hide the resource server URL from the authorization server. Change it into: The use of logical names or of physical addresses leads to privacy concerns, since in such a case the Authorisation Server will be able to know exactly where every access token will be used by every client. In order to address this privacy concern, authorization servers should associate an access token with a certain resource server without, in any way, being able to know which resource server is being designated. For Authorisation Servers, the audience value should be or look like a random number. At the moment, none of the OAuth RFCs describes such a technique. However, solving this issue is technically possible in several ways. Instead of a URL, it has been suggested to use the fingerprint of the resource server’s X.509 certificate as audience value. This variant allows to detect an attempt to spoof the legit resource server’s URL by using a valid TLS certificate obtained from a different CA. However, such a variant, by successive trials, might still allow an Authorisation Server to identify the resource servers. Denis > Hi all, > > the new revision adds an extensive section on access token leakage at > the resource server > (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03#section-4.4). > > I tried to incorporate all contributions and feedback given at the > OAuth security workshop and the WG session in Prague. > > Please give us feedback. > > kind regards, > Torsten. > >> Am 10.09.2017 um 19:22 schrieb internet-drafts@ietf.org >> <mailto:internet-drafts@ietf.org>: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the >> IETF. >> >> Title : OAuth Security Topics >> Authors : Torsten Lodderstedt >> John Bradley >> Andrey Labunets >> Filename : draft-ietf-oauth-security-topics-03.txt >> Pages : 27 >> Date : 2017-09-10 >> >> Abstract: >> This draft gives a comprehensive overview on open OAuth security >> topics. It is intended to serve as a working document for the OAuth >> working group to systematically capture and discuss these security >> topics and respective mitigations and eventually recommend best >> current practice and also OAuth extensions needed to cope with the >> respective security threats. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-03 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] I-D Action: draft-ietf-oauth-security-… internet-drafts
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Torsten Lodderstedt
- Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-secur… Denis