Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt: Collaborative attacks against a Verifier

[Denis <[e-mail]>]

Hi Daniel,
>
> Hi Denis,
>
> a discussion on claims-based/biometric binding, probably what you're 
> hinting at,
>
I am not hinting at a discussion "on claims-based/biometric binding".

> is out of the scope of this document, since we define neither 
> mechanisms nor rules for that.
>
> This should be part of a discussion with a larger scope, like the 
> Security & Trust document in OIDF's DCP group.
>
RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) 
states in its Introduction section:

      All RFCs are required by RFC 2223 to contain a Security 
Considerations section. The purpose of this is both to encourage
      document authors to consider security in their designs and to 
inform the reader of relevant security issues.

Section 5 of RFC 3552 states:

      5. Writing Security Considerations Sections

      (...)

      There should be a clear description of the kinds of threats on the 
described protocol or technology. This should be approached as an
      effort to perform "due diligence" in describing *all known or 
foreseeable risks and threats *to potential implementers and users.

      Authors MUST describe

        1. which attacks are out of scope (and why!)
        2. which attacks are in-scope
            2.1 and the protocol is susceptible to
            2.2 and the protocol protects against

"Collaborative attacks against a Verifier" should be added to the 
Security Considerations section.

Denis

> -Daniel
>
> Am 26.10.23 um 11:01 schrieb Denis:
>> Hi All,
>>
>> Section 11.6. is about "Key Binding" which is indeed an important 
>> security feature.
>> However, in the context of "selective disclosure" while this feature 
>> is essential, it is insufficient.
>>
>> Let us take an example: If a Token indicates that an individual has 
>> the nationality X, in case of a collusion between two individuals
>> and when using two pieces of software specifically developed for that 
>> purpose, an individual would be able to compute and transmit
>> a Token to another individual for the benefit of that other 
>> individual in order to cheat a Verifier. This is a collusion between 
>> two individuals.
>>
>> The first individual may not have the knowledge of the private key 
>> but since he has the use of the private key, he is in a position to sign
>> anything he wants. Since the Token does not include claims allowing 
>> to uniquely identity the individual, "if he is not seen, he will not 
>> be caught".
>>
>> "Collaborative attacks against a Verifier" should be added to the 
>> Security Considerations section.
>>
>> There exist ways to counter collaborative attacks against a Verifier. 
>> These ways should be mentioned in the core of the document.
>>
>> Denis
>>
>>> Hi all,
>>>
>>> this release of SD-JWT includes one important normative change, 
>>> which is a hash in the key binding JWT to ensure the integrity of 
>>> presentations. The second biggest change is that we restructured 
>>> some sections of the document to make it more readable.
>>>
>>> As always, we're looking forward to discussing SD-JWT here on the 
>>> mailing list and in Prague.
>>>
>>> -Daniel
>>>
>>> This is the full changelog:
>>>
>>>    -06
>>>
>>>     *  Added hash of Issuer-signed part and Disclosures in KB-JWT
>>>
>>>     *  Fix minor issues in some examples
>>>
>>>     *  Added IANA media type registration request for the JSON
>>>        Serialization
>>>
>>>     *  More precise wording around storing artifacts with sensitive data
>>>
>>>     *  The claim name _sd or ... must not be used in a disclosure.
>>>
>>>     *  Added JWT claims registration requests to IANA
>>>     *  Ensure claims that control validity are checked after decoding
>>>        payload
>>>
>>>     *  Restructure sections around data formats and Example 1
>>>
>>>     *  Update JSON Serialization to remove the kb_jwt member and allow
>>>        for the disclosures to be conveyed elsewhere
>>>
>>>     *  Expand the Enveloping SD-JWTs section to also discuss enveloping
>>>        JSON serialized SD-JWTs
>>>
>>> Am 23.10.23 um 18:17 schrieb [e-mail]:
>>>> Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now
>>>> available. It is a work item of the Web Authorization Protocol (OAUTH) WG of
>>>> the IETF.
>>>>
>>>>     Title:   Selective Disclosure for JWTs (SD-JWT)
>>>>     Authors: Daniel Fett
>>>>              Kristina Yasuda
>>>>              Brian Campbell
>>>>     Name:    draft-ietf-oauth-selective-disclosure-jwt-06.txt
>>>>     Pages:   90
>>>>     Dates:   2023-10-23
>>>>
>>>> Abstract:
>>>>
>>>>     This specification defines a mechanism for selective disclosure of
>>>>     individual elements of a JSON object used as the payload of a JSON
>>>>     Web Signature (JWS) structure.  It encompasses various applications,
>>>>     including but not limited to the selective disclosure of JSON Web
>>>>     Token (JWT) claims.
>>>>
>>>> The IETF datatracker status page for this Internet-Draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
>>>>
>>>> There is also an HTML version available at:
>>>> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html
>>>>
>>>> A diff from the previous version is available at:
>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-06
>>>>
>>>> Internet-Drafts are also available by rsync at:
>>>> rsync.ietf.org::internet-drafts
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> -- 
>>> Please use my new email address:[e-mail]
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> -- 
> Please use my new email address:[e-mail]
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth