Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

[Denis <[e-mail]>]

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 <[e-mail] 
>> <mailto:[e-mail]>> 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: [phone]
>>
>>
>>
>> On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig 
>> <[e-mail] <mailto:[e-mail]>> 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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth