Hello Jared,
You raised the following question :
*
**Should other possible threats and vulnerabilities be included?
Meaning, is the list the definitive known list?*
This list is certainly not a "definitive /known /list" since there
exists an additional /known /threat that has been advertised to this list
for the fist time *exactly* 3 years ago. It is the right time to blow
three candles !
This is not either "the best list of things that we have at this time",
as Justin mentioned.
The current document only addresses external "attackers". The case of
collusion between users is not mentioned.
The first description of such a kind of attack, named the "*Alice and
Bob Collusion*" attack, was mentioned on this list
*on November the 7 th, 2016*. It is available at:
https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html
Considering collaborative users is critical when considering age
verification. If a user legitimately obtains one attribute demonstrating
that he is over 18 and if that user voluntarily transmits such an
attribute to another user that is below 18, the RP should be in a position
to detect that the attribute does not belong to that other user and
should thus be in a position to reject it.
It is often believed that protecting secret keys or private keys in a
secure element is an efficient and sufficient way to prevent such a
collusion
attack between users against a RP. However, this is not true. There have
been some implementations using OAuth and smart cards, but the simple
addition
of these two elements does not necessarily provide a secure solution.
The first user is in a position to perform all the cryptographic
computations that the other user needs since it can perform any
cryptographic computation
that the other user needs using secret or private key stored in his
secure element.
*Whatever kind of cryptographic is being used, when two users
collaborate, a software-only solution will be unable to prevent the
transmission *
* of an attribute of a user that possess it to another user that
does not possess it. *
**
Additional functional properties are required for the secure element and
the presence of those properties needs to be verified both by the RP
and the Authorization Server. There are six roles to be considered in
order to be able to counter the Alice and Bob Collusion attack, namely:
* Users (usually human users),
* Clients,
* Secure Elements (SE),
* Authorization Servers (AS),
* Relying Parties (RP), and
* Secure Element Providers (SEP).
Note: Since RFC 6819 (OAuth 2.0 Threat Model and Security
Considerations*) *does not include any figure, a figure illustrating
these roles would be really helpful for the readers.
As a consequence, the protocols SHALL support exchanges where
computations performed by the secure elements are part of the protocols.
I understand that it may be embarrassing to describe in this document an
attack that cannot be countered using any of the OAuth 2.0 Security Best
Current Practices
.... but this is not a reason to conceal user's collaborative attacks in
this document.
The fact is that any (secure) solution to the ABC attack SHALL be based
on the use of secure elements and hence CANNOT be based on the use of a
software only solution,
whatever kind of cryptographic algorithms would be used.
I believe that some of the material provided both in this email and in
the email from November the 7 th, 2016 should be incorporated into this
document
in order to address this missing threat.
Denis
1. Normative MUST/REQUIRED is fine in a BCP.
2. This is not the definitive list, but instead the best list of
things that we have at this time. There will be more attacks, and more
mitigations for those attacks.
— Justin
On Nov 6, 2019, at 3:16 PM, Jared Jennings <jaredljenni...@gmail.com
<mailto:jaredljenni...@gmail.com>> wrote:
Hi,
This is my first time reviewing a document or responding to the
group. So, with that introduction feel free to guide me along the way.
Reading through the document, I had a few high-level questions first.
I will have more detailed comments later, once I know I'm on the
right track and I assume those comments I should just share with the
mailing list?
1. Since the document is a "Best Practices" document, are the words
"MUST" and "REQUIRED" and other definitive terms? Would instead
SHOULD and RECOMMENDED be used?
2. Should other possible threats and vulnerabilities be included?
Meaning, is the list the definitive known list?
Thanks!
-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152
On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig
<hannes.tschofe...@arm.com <mailto:hannes.tschofe...@arm.com>> wrote:
Hi all,
this is a working group last call for "OAuth 2.0 Security Best
Current Practice".
Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
Please send you comments to the OAuth mailing list by Nov. 27, 2019.
(We use a three week WGLC because of the IETF meeting.)
Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do
not disclose the contents to any other person, use it for any
purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
