Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-04.txt

Denis <denis.ietf@free.fr> Wed, 15 November 2017 11:53 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 82D4C126B6E for <oauth@ietfa.amsl.com>; Wed, 15 Nov 2017 03:53:16 -0800 (PST)
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 jEw3KL6uuNp7 for <oauth@ietfa.amsl.com>; Wed, 15 Nov 2017 03:53:14 -0800 (PST)
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 A77A0126FB3 for <oauth@ietf.org>; Wed, 15 Nov 2017 03:53:13 -0800 (PST)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id F285A7802B2 for <oauth@ietf.org>; Wed, 15 Nov 2017 12:53:11 +0100 (CET)
To: oauth@ietf.org
References: <151066014057.5874.14995601908173317919@ietfa.amsl.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <17a930bd-fc0e-d2b7-a558-b2e8a7a975aa@free.fr>
Date: Wed, 15 Nov 2017 12:53:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <151066014057.5874.14995601908173317919@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------D082280A4B9094AFA50262EA"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/BckMNsUBrldyEErf4O0yrYditx8>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-04.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: Wed, 15 Nov 2017 11:53:16 -0000

Comments on draft-ietf-oauth-security-topics-04

1. Section 2.2 states:

    2.2.  Token Leakage Prevention
        Authorization servers _*shall*_ use TLS-based methods for sender
        constraint access tokens as described in section Section 4.7.1.2,
        such as token binding [I-D.ietf-oauth-token-binding] or Mutual TLS
        for OAuth 2.0 [I-D.ietf-oauth-mtls].  It is also recommend to use
        end-to-end TLS whenever possible.

Since this draft is intended to be a Best Current Practice (BCP) 
document , "shall" should be replaced by "should".


2. Collusion between clients is not addressed but should be mentioned. 
It is proposed to add a section
that would placed before section 4.7 (Access Token Leakage at the 
Resource Server) that would have the following content:

    Access Token Leakage at the client

    It’s been a while since the OAuth WG has published in RFC 6819
    [RFC6819]. At this time, the threat model was considering
    various types of attacks performed by attackers or by Resource
    Servers but did not take into consideration collusion between clients.

    A client could legitimately obtain an access token and then could
    attempt to allow its use by another client. If the access token
    contains
    a sufficient number of attributes that allows to unambiguously
    identify the client, it is unlikely that the legitimate client will
    transmit it
    to another client since that other client would be able to
    impersonate the legitimate client. However, if it is not the case
    (e.g. the access token
    contains a single attribute like "over 18"), the legitimate owner of
    the access token may be willing to collaborate with another client
    because
    the collusion will not be seen by the Authorization server nor the
    Resource Server.

    While protecting private keys in secure elements or in TPMs is
    certainly necessary, it is insufficient since the legitimate owner
    of the access token
    would be able to perform all the cryptographic computations that the
    other client needs.

    The counter-measures described in section 4.7.1.2 (Sender
    Constrained Access Tokens) are unable to counter collusion between
    clients.


3. A section about privacy considerations is missing. It is proposed to 
add a section 8 with the following content:

    8. Privacy considerations

    Techniques able to solve security concerns are not necessarily able
    to solve privacy concerns. The counter-measures described in section
    4.7.1.3
    (Audience Restricted Access Tokens) allow authorization servers to
    know where each token they issue will be used. This may be a privacy
    concern
    for some clients. Current techniques do not address a way to prevent
    authorization servers to know where the tokens they issue will be used.
    This leaves room to extend OAuth in order to add privacy properties.

Denis

> 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-04.txt
> 	Pages           : 26
> 	Date            : 2017-11-14
>
> 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-04
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-04
>
>
> 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