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

[Denis <[e-mail]>]

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 [e-mail] 
>> <mailto:[e-mail]>:
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth