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-dra...@ietf.org
<mailto:internet-dra...@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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
