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