Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

> On 7 Nov 2023, at 15:50, Denis  wrote:
> 
> Hi Neil,
> 
>> On 7 Nov 2023, at 13:13, Denis > > wrote:
>>> 
>>> Hi Neil,
>>> 
>>> You wrote:
>>> "Note that unlinkability is explicitly already not a goal for SD-JWT 
>>> according to section 12.4".
>>> This is untrue:
>>> 12.4.  Unlinkability
>>> 
>>> Colluding Issuer/Verifier or Verifier/Verifier pairs could link 
>>> issuance/presentation or two presentation sessions to the same user
>>> on the basis of unique values encoded in the SD-JWT (Issuer signature, 
>>> salts, digests, etc.).
>>> 
>>> To prevent these types of linkability, various methods, including but not 
>>> limited to the following ones can be used:
>>> 
>>> - Use advanced cryptographic schemes, outside the scope of this 
>>> specification.
>>> 
>>> - Issue a batch of SD-JWTs to the Holder to enable the Holder to use a 
>>> unique SD-JWT per Verifier. 
>>>This only helps with Verifier/Verifier unlinkability.
>>> This means using single-use credentials and issuing in advance credentials 
>>> batches, each one with a different holder-public key in it .
>> 
>> The very first sentence of that section clearly states that SD-JWTs can be 
>> linked. The fact that it also mentions other things you can do, 
>> entirely orthogonal to the use of SD-JWT, doesn't contradict that, it rather 
>> reinforces it. (As I've said previously when SD-JWT was first proposed, 
>> if you are willing to issue a batch of credentials then you don't need 
>> SD-JWT at all: just issue normal JWTs with subsets of claims 
>> matching anticipated selective disclosure cases. In all the concrete 
>> use-cases I've seen, this is not a large number of combinations).
> 1) If some people are willing to support the Verifier/Verifier unlinkability 
> property, the document should provide more guidance 
> since a solution that does not use advanced cryptographic schemes is at hand. 
> Otherwise, the fact that the Verifier/Verifier 
> unlinkability property is not supported should be advertised in Section 1.1.  
> "Feature Summary". 
> 
I think that part of it is fine as it is. It states the properties it does 
support up-front and mentions things it doesn’t support in the security/privacy 
considerations. That seems pretty standard practice. I wouldn’t object to the 
authors adding text clarifying that to the summary, but it doesn’t seem 
necessary to me.

> 2) If you just issue normal JWTs with subsets of claims matching anticipated 
> selective disclosure cases, the burden is rather the same for the Holder: 
> it needs to generate a different key pair for every SD-JWT. As soon as a 
> SD-JWT will be used towards a Verifier, it should be discarded 
> so that it cannot be reused towards another Verifier.  This approach might 
> quadruple the number of JWTs to ask in advance.
> 
I’m not sure I follow this logic. You want to issue multiple single-use SD-JWTs 
to ensure unlinkability, but think it’s too much to issue multiple normal JWTs?

Anyway, this is getting somewhat off the point. SD-JWTs as specified contain no 
features to support unlinkability and this is clearly not a goal of the spec. 
The fact that you might want it to be a goal doesn’t make it so.

>> 
>>> 
>>> So, I generally agree with Watson.
>>> 
>>> Currently, the SPICE BoF tentative charter is considering Verifier/Verifier 
>>> unlinkability to be within the charter. 
>>> 
>>> You also wrote:
>>> Allowing an attacker to selectively disclose that a token has expired seems 
>>> problematic to say the least
>>> Why an "attacker" ? This is not problem as soon as a SD-JWT is only used 
>>> once.
>> 
>> The point of these kinds of security constraints (which are indeed mostly 
>> constraints and not claims), is to prevent certain attacks. 
>> Such as restricting the time-window in which a token can be used, so that if 
>> it is stolen there is a limit to how long it can be abused. 
>> The "attacker" here could be a third party that intercepts/phishes the 
>> token, or it could be a malicious Verifier, etc. If these constraints 
>> can be selectively disclosed then they are utterly useless in preventing the 
>> attacks they are designed to stop: time-limited tokens become 
>> unlimited time usage, key-bound tokens become bearer tokens, and single-use 
>> tokens become multiple-use. 
>> To say this is a *spectacularly* bad idea is an understatement. 
> The point is not to use selective disclosure on claims that prevent certain 
> attacks. 
> 
Indeed, which is what I suggested. Watson Ladd suggested this would lead to 
some kind of privacy leak, which you agreed with. I take it now that you don’t 
agree with that, but instead agree with me that there are certain claims that 
shouldn’t be selectively disclosable?

— Neil___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Denis]

Hi Neil,


On 7 Nov 2023, at 13:13, Denis  wrote:


Hi Neil,

You wrote:

"Note that unlinkability is explicitly already not a goal for SD-JWT according 
to section 12.4".

This is untrue:

12.4.  Unlinkability

Colluding Issuer/Verifier or Verifier/Verifier pairs could link
issuance/presentation or two presentation sessions to the same user
on the basis of unique values encoded in the SD-JWT (Issuer
signature, salts, digests, etc.).

To prevent these types of linkability, various methods, including
but not limited to the following ones can be used:

- Use advanced cryptographic schemes, outside the scope of this
specification.

-*Issue a batch of SD-JWTs to the Holder to enable the Holder to
use a unique SD-JWT per Verifier*.
   This only helps with Verifier/Verifier unlinkability.

This means using*single-use credentials*and issuing in advance 
credentials batches, each one with a different holder-public key in it .


The very first sentence of that section clearly states that SD-JWTs 
can be linked. The fact that it also mentions other things you can do,
entirely orthogonal to the use of SD-JWT, doesn't contradict that, it 
rather reinforces it. (As I've said previously when SD-JWT was first 
proposed,
if you are willing to issue a batch of credentials then you don't need 
SD-JWT at all: just issue normal JWTs with subsets of claims
matching anticipated selective disclosure cases. In all the concrete 
use-cases I've seen, this is not a large number of combinations).


1) If some people are willing to support the Verifier/Verifier 
unlinkability property, the document should provide more guidance
since a solution that does not use advanced cryptographic schemes is at 
hand. Otherwise, the fact that the Verifier/Verifier
unlinkability property is not supported should be advertised in Section 
1.1.  "Feature Summary".


2) If you just issue normal JWTs with subsets of claims matching 
anticipated selective disclosure cases, the burden is rather the same 
for the Holder:
it needs to generate a different key pair for every SD-JWT. As soon as a 
SD-JWT will be used towards a Verifier, it should be discarded
so that it cannot be reused towards another Verifier.  This approach 
might quadruple the number of JWTs to ask in advance.






So, I generally agree with Watson.

Currently, the SPICE BoF/tentative/charter is considering 
Verifier/Verifier unlinkability to be within the charter.


You also wrote:

Allowing an attacker to selectively disclose that a token has expired seems 
problematic to say the least

Why an "attacker" ? This is not problem as soon as a SD-JWT is only 
used once.


The point of these kinds of security constraints (which are indeed 
mostly constraints and not claims), is to prevent certain attacks.
Such as restricting the time-window in which a token can be used, so 
that if it is stolen there is a limit to how long it can be abused.
The "attacker" here could be a third party that intercepts/phishes the 
token, or it could be a malicious Verifier, etc. If these constraints
can be selectively disclosed then they are utterly useless in 
preventing the attacks they are designed to stop: time-limited tokens 
become
unlimited time usage, key-bound tokens become bearer tokens, and 
single-use tokens become multiple-use.

To say this is a *spectacularly* bad idea is an understatement.


The point is not to use selective disclosure on claims that prevent 
certain attacks.

Since these claims are used only once, they can be made unlinkable.

Denis



-- Neil



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

On 7 Nov 2023, at 13:13, Denis  wrote:
> 
> Hi Neil,
> 
> You wrote:
> "Note that unlinkability is explicitly already not a goal for SD-JWT 
> according to section 12.4".
> This is untrue:
> 12.4.  Unlinkability
> 
> Colluding Issuer/Verifier or Verifier/Verifier pairs could link 
> issuance/presentation or two presentation sessions to the same user
> on the basis of unique values encoded in the SD-JWT (Issuer signature, salts, 
> digests, etc.).
> 
> To prevent these types of linkability, various methods, including but not 
> limited to the following ones can be used:
> 
> - Use advanced cryptographic schemes, outside the scope of this specification.
> 
> - Issue a batch of SD-JWTs to the Holder to enable the Holder to use a unique 
> SD-JWT per Verifier. 
>This only helps with Verifier/Verifier unlinkability.
> This means using single-use credentials and issuing in advance credentials 
> batches, each one with a different holder-public key in it .

The very first sentence of that section clearly states that SD-JWTs can be 
linked. The fact that it also mentions other things you can do, entirely 
orthogonal to the use of SD-JWT, doesn't contradict that, it rather reinforces 
it. (As I've said previously when SD-JWT was first proposed, if you are willing 
to issue a batch of credentials then you don't need SD-JWT at all: just issue 
normal JWTs with subsets of claims matching anticipated selective disclosure 
cases. In all the concrete use-cases I've seen, this is not a large number of 
combinations).

> 
> So, I generally agree with Watson.
> 
> Currently, the SPICE BoF tentative charter is considering Verifier/Verifier 
> unlinkability to be within the charter. 
> 
> You also wrote:
> Allowing an attacker to selectively disclose that a token has expired seems 
> problematic to say the least
> Why an "attacker" ? This is not problem as soon as a SD-JWT is only used once.

The point of these kinds of security constraints (which are indeed mostly 
constraints and not claims), is to prevent certain attacks. Such as restricting 
the time-window in which a token can be used, so that if it is stolen there is 
a limit to how long it can be abused. The "attacker" here could be a third 
party that intercepts/phishes the token, or it could be a malicious Verifier, 
etc. If these constraints can be selectively disclosed then they are utterly 
useless in preventing the attacks they are designed to stop: time-limited 
tokens become unlimited time usage, key-bound tokens become bearer tokens, and 
single-use tokens become multiple-use. To say this is a *spectacularly* bad 
idea is an understatement. 

-- Neil



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Denis]

Hi Neil,

You wrote:

   "Note that unlinkability is explicitly already not a goal for SD-JWT according to 
section 12.4".

This is untrue:

   12.4.  Unlinkability

   Colluding Issuer/Verifier or Verifier/Verifier pairs could link
   issuance/presentation or two presentation sessions to the same user
   on the basis of unique values encoded in the SD-JWT (Issuer
   signature, salts, digests, etc.).

   To prevent these types of linkability, various methods, including
   but not limited to the following ones can be used:

   - Use advanced cryptographic schemes, outside the scope of this
   specification.

   - *Issue a batch of SD-JWTs to the Holder to enable the Holder to
   use a unique SD-JWT per Verifier*.
   This only helps with Verifier/Verifier unlinkability.

This means using *single-use credentials *and issuing in advance 
credentials batches, each one with a different holder-public key in it .


So, I generally agree with Watson.

Currently, the SPICE BoF /tentative /charter is considering 
Verifier/Verifier unlinkability to be within the charter.


You also wrote:

   Allowing an attacker to selectively disclose that a token has expired seems 
problematic to say the least

Why an "attacker" ? This is not problem as soon as a SD-JWT is only used 
once.


Denis




On 6 Nov 2023, at 16:43, Watson Ladd  wrote:

On Mon, Nov 6, 2023 at 5:46 AM Neil Madden  wrote:


How about the following:

—
An Issuer MUST NOT allow any security-critical claim to be selectively 
disclosable. The exact list of “security-critical” claims will depend on the 
application, and SHOULD be listed by any application-specific profile of 
SD-JWT. The following is a list of standard claim names that SHOULD be 
considered as security-critical by any SD-JWT Issuer:

* “iss” (Issuer)
* “aud” (Audience), although issuers may want to allow individual entries in 
the array to be selectively-disclosable
* “exp” (Expiration Time)
* “nbf” (Not Before)
* “iat” (Issued At)
* “jti” (JWT ID)

In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively 
disclosable.
---


I think these fields can have significant unanticipated privacy
impacts. Expiry and issuance times can have very high entropy.

Can you expand on what you mean? What privacy threat do you envision? Note that 
unlinkability is explicitly already not a goal for SD-JWT according to section 
12.4.

Allowing an attacker to selectively disclose that a token has expired seems 
problematic to say the least.

— Neil
___
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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Brian Campbell]

Hi Neil. Thank you for suggesting text! I agree we’re closing in on some
actionable changes here (I've added some issues in the github repo to keep
track FWIW) and we'll work to incorporate the text you've suggested.

I do see how the text you've cited in 11.8 11.6, and 8.3 (there is no 8.4
so making an assumption) could be read as ruling out the kind of migration
path you've described (though admittedly I have a more liberal reading). I
do agree that we don't want to outright disallow that kind of migration.
But I want to be really thoughtful about any changes that might be made in
that area. I think it's very important to convey the general
principle/requirement that a verifier have a validation policy that isn't
unduly/unexpectedly influenced by the (sometimes attacker-controllable)
content of the token. A verifier's policy might have some conditionality as
appropriate for a specific context (such as migration) but the verifier has
to have a concrete policy around validation and acceptance.


On Mon, Nov 6, 2023 at 6:44 AM Neil Madden  wrote:

> Hi Brian,
>
> Apologies for the late reply. I *think* we’re closing in on agreement
> here. Comments and some wording suggestions inline below.
>
> On 27 Oct 2023, at 00:26, Brian Campbell 
> wrote:
>
> Thanks Neil!  Appreciate the productive discussion. Some more responses
> below (while also attempting to snip out and declutter the message).
>
> On Thu, Oct 26, 2023 at 7:03 AM Neil Madden 
> wrote:
>
> On 25 Oct 2023, at 22:00, Brian Campbell 
> wrote:
>
>  
>
>>
>> The draft currently says that second-preimage resistance is needed, which
>> prevents a malicious Holder from finding a different Disclosure value that
>> results in a digest that's the same as one in the signed credential.
>> Protecting against a malicious user effectively forging or modifying
>> disclosed claim names/values is the security objective. Second-preimage
>> resistance is not as strong as collision resistance but I believe is
>> correct and sufficient for the context of use. And a malicious Issuer isn't
>> something that's in scope and could do all kinds of other bad things. This
>> is the section of the security considerations with that:
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5
>>
>>
>> Ok, that is a fair enough stance. Without requiring collision resistance
>> though it does make SD-JWT a slightly weird signature scheme, in that the
>> issuer is not actually committed to the contents of the token like they
>> would be for a normal signed JWT. That is a surprising property. For
>> example, if you store SD-JWTs for audit trail purposes (as some people do
>> for normal JWTs), the contents are potentially repudiable. Like you say, if
>> you trust the issuer then maybe that is fine, but it’s a sharp edge that
>> maybe it would be better to remove? Given that pretty much any hash
>> function that is likely to be used with SD-JWT will almost certainly be CR
>> anyway.
>>
>
> As a compromise of sorts - would you be willing to propose some additional
> text to go in section 11.5 that (maybe strongly) recommends the hash
> function be collision resistant?
>
>
> How about the following?
>
> —
> To ensure privacy of claims that are not being selectively disclosed in a
> given presentation, the hash function MUST ensure that it is infeasible to
> calculate the salt and claim name and value (or any portion thereof) that
> results in a particular digest. This implies the hash function MUST be
> preimage resistant, but should also not allow an observer to infer any
> partial information about the undisclosed content. In the terminology of
> cryptographic commitment schemes, the hash function MUST be computationally
> hiding.
>
> The hash function MUST be second-preimage resistant. For any salt and
> claim value pair, it is infeasible to find a different salt and claim value
> pair that result in the same digest.
>
> The hash function SHOULD also be collision resistant. Although not
> essential to the anticipated uses of SD-JWT, without collision resistance
> an Issuer may be able to find multiple disclosures that have the same hash
> value. The signature over the SD-JWT would not then commit the Issuer to
> the contents of the JWT, which is surprising. Where this is a concern, the
> collision resistance of the hash function SHOULD match the collision
> resistance of the hash function used by the signature scheme. For example,
> use of the ES512 signature algorithm would require a disclosure hash
> function with at least 256-bit collision resistance, such as SHA-512.
> —
>
> (I’d like to add an informational reference defining these terms, but I
> can’t find a good one - even the NIST/FIPS standards seem to just take
> terms like “collision resistance” for granted, so maybe we can too?)
>
>
> I'm envisioning the resultant 11.5 section saying that the hash function
> MUST be second-preimage resistant and fully irreversible (as it does/will
> 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

> On 6 Nov 2023, at 16:43, Watson Ladd  wrote:
> 
> On Mon, Nov 6, 2023 at 5:46 AM Neil Madden  wrote:
> 
>> 
>> How about the following:
>> 
>> —
>> An Issuer MUST NOT allow any security-critical claim to be selectively 
>> disclosable. The exact list of “security-critical” claims will depend on the 
>> application, and SHOULD be listed by any application-specific profile of 
>> SD-JWT. The following is a list of standard claim names that SHOULD be 
>> considered as security-critical by any SD-JWT Issuer:
>> 
>> * “iss” (Issuer)
>> * “aud” (Audience), although issuers may want to allow individual entries in 
>> the array to be selectively-disclosable
>> * “exp” (Expiration Time)
>> * “nbf” (Not Before)
>> * “iat” (Issued At)
>> * “jti” (JWT ID)
>> 
>> In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively 
>> disclosable.
>> ---
>> 
> 
> I think these fields can have significant unanticipated privacy
> impacts. Expiry and issuance times can have very high entropy.

Can you expand on what you mean? What privacy threat do you envision? Note that 
unlinkability is explicitly already not a goal for SD-JWT according to section 
12.4. 

Allowing an attacker to selectively disclose that a token has expired seems 
problematic to say the least. 

— Neil
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Watson Ladd]

On Mon, Nov 6, 2023 at 5:46 AM Neil Madden  wrote:

>
> How about the following:
>
> —
> An Issuer MUST NOT allow any security-critical claim to be selectively 
> disclosable. The exact list of “security-critical” claims will depend on the 
> application, and SHOULD be listed by any application-specific profile of 
> SD-JWT. The following is a list of standard claim names that SHOULD be 
> considered as security-critical by any SD-JWT Issuer:
>
>  * “iss” (Issuer)
>  * “aud” (Audience), although issuers may want to allow individual entries in 
> the array to be selectively-disclosable
>  * “exp” (Expiration Time)
>  * “nbf” (Not Before)
>  * “iat” (Issued At)
>  * “jti” (JWT ID)
>
> In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively 
> disclosable.
> ---
> 

I think these fields can have significant unanticipated privacy
impacts. Expiry and issuance times can have very high entropy.

>
> Best wishes,
>
> Neil
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



-- 
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

Hi Brian,

Apologies for the late reply. I *think* we’re closing in on agreement here. 
Comments and some wording suggestions inline below.

> On 27 Oct 2023, at 00:26, Brian Campbell  wrote:
> 
> Thanks Neil!  Appreciate the productive discussion. Some more responses below 
> (while also attempting to snip out and declutter the message).
> 
> On Thu, Oct 26, 2023 at 7:03 AM Neil Madden  > wrote:
>> On 25 Oct 2023, at 22:00, Brian Campbell > > wrote:
> 
>  
>>> 
>>> The draft currently says that second-preimage resistance is needed, which 
>>> prevents a malicious Holder from finding a different Disclosure value that 
>>> results in a digest that's the same as one in the signed credential. 
>>> Protecting against a malicious user effectively forging or modifying 
>>> disclosed claim names/values is the security objective. Second-preimage 
>>> resistance is not as strong as collision resistance but I believe is 
>>> correct and sufficient for the context of use. And a malicious Issuer isn't 
>>> something that's in scope and could do all kinds of other bad things. This 
>>> is the section of the security considerations with that: 
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5
>> 
>> Ok, that is a fair enough stance. Without requiring collision resistance 
>> though it does make SD-JWT a slightly weird signature scheme, in that the 
>> issuer is not actually committed to the contents of the token like they 
>> would be for a normal signed JWT. That is a surprising property. For 
>> example, if you store SD-JWTs for audit trail purposes (as some people do 
>> for normal JWTs), the contents are potentially repudiable. Like you say, if 
>> you trust the issuer then maybe that is fine, but it’s a sharp edge that 
>> maybe it would be better to remove? Given that pretty much any hash function 
>> that is likely to be used with SD-JWT will almost certainly be CR anyway. 
> 
> 
> As a compromise of sorts - would you be willing to propose some additional 
> text to go in section 11.5 that (maybe strongly) recommends the hash function 
> be collision resistant?

How about the following?

—
To ensure privacy of claims that are not being selectively disclosed in a given 
presentation, the hash function MUST ensure that it is infeasible to calculate 
the salt and claim name and value (or any portion thereof) that results in a 
particular digest. This implies the hash function MUST be preimage resistant, 
but should also not allow an observer to infer any partial information about 
the undisclosed content. In the terminology of cryptographic commitment 
schemes, the hash function MUST be computationally hiding.

The hash function MUST be second-preimage resistant. For any salt and claim 
value pair, it is infeasible to find a different salt and claim value pair that 
result in the same digest.

The hash function SHOULD also be collision resistant. Although not essential to 
the anticipated uses of SD-JWT, without collision resistance an Issuer may be 
able to find multiple disclosures that have the same hash value. The signature 
over the SD-JWT would not then commit the Issuer to the contents of the JWT, 
which is surprising. Where this is a concern, the collision resistance of the 
hash function SHOULD match the collision resistance of the hash function used 
by the signature scheme. For example, use of the ES512 signature algorithm 
would require a disclosure hash function with at least 256-bit collision 
resistance, such as SHA-512.
—

(I’d like to add an informational reference defining these terms, but I can’t 
find a good one - even the NIST/FIPS standards seem to just take terms like 
“collision resistance” for granted, so maybe we can too?)

> 
> I'm envisioning the resultant 11.5 section saying that the hash function MUST 
> be second-preimage resistant and fully irreversible (as it does/will now with 
> slightly updated wording discussed below) but then also goes on to say that 
> it SHOULD just be collision resistant. I can come up with some text 
> recommending CR too but maybe not with the rationale/explanation as you 
> could. 
> 
>  
>  
>>> Preimage resistance maybe isn’t the term to use there. It’s used in that 
>>> section-11.5 
>>> 
>>>  along with some text that says that it needs to be “infeasible to 
>>> calculate the salt and claim value that result in a particular digest”.  We 
>>> are trying to say that the hash has to have the property that it can’t be 
>>> reversed (or even partially reversed, to your point). There’s probably a 
>>> better way to state that the hash function has to be not at all reversible. 
>>> Can you perhaps suggest some text? Or could we just replace “preimage 
>>> resistant” with “irreversible” in that text in 11.5? And maybe qualify that 
>>> text a bit more 

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

[Daniel Fett]

Hi Denis,

Am 31.10.23 um 17:10 schrieb Denis:

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".


Ok.


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



We will consider this.

-Daniel



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 internet-dra...@ietf.org:

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

--
Please use my new email address:m...@danielfett.de

___
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

--
Please use my new email address:m...@danielfett.de

___
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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Denis]

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 internet-dra...@ietf.org:

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

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

[Daniel Fett]

Hi Denis,

a discussion on claims-based/biometric binding, probably what you're 
hinting at, 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.


-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 internet-dra...@ietf.org:

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

--
Please use my new email address:m...@danielfett.de

___
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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Brian Campbell]

On Thu, Oct 26, 2023 at 5:26 PM Brian Campbell 
wrote:

>
> I think you might underestimate the difficulty in
> creating/changing/establishing such a registry and overestimate its
> effectiveness and usefulness. And I think the  selective disclosability
> treatment of many claims is ultimately context dependent. As I've said, I'm
> all for strengthening and improving the text in this section. But don't
> believe that involves a registry.
>

One more quick thing here: maintaining a registry also isn't free, which I
say as one of the so-called designated experts on the JWT claims registry.
I don't want to and don't feel equipped to evaluate a selective
disclosability part of claims registration requests. Or try and say what it
should be for all the existing registered claims.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Brian Campbell]

Thanks Neil!  Appreciate the productive discussion. Some more responses
below (while also attempting to snip out and declutter the message).

On Thu, Oct 26, 2023 at 7:03 AM Neil Madden  wrote:

On 25 Oct 2023, at 22:00, Brian Campbell  wrote:

 

>
> The draft currently says that second-preimage resistance is needed, which
> prevents a malicious Holder from finding a different Disclosure value that
> results in a digest that's the same as one in the signed credential.
> Protecting against a malicious user effectively forging or modifying
> disclosed claim names/values is the security objective. Second-preimage
> resistance is not as strong as collision resistance but I believe is
> correct and sufficient for the context of use. And a malicious Issuer isn't
> something that's in scope and could do all kinds of other bad things. This
> is the section of the security considerations with that:
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5
>
>
> Ok, that is a fair enough stance. Without requiring collision resistance
> though it does make SD-JWT a slightly weird signature scheme, in that the
> issuer is not actually committed to the contents of the token like they
> would be for a normal signed JWT. That is a surprising property. For
> example, if you store SD-JWTs for audit trail purposes (as some people do
> for normal JWTs), the contents are potentially repudiable. Like you say, if
> you trust the issuer then maybe that is fine, but it’s a sharp edge that
> maybe it would be better to remove? Given that pretty much any hash
> function that is likely to be used with SD-JWT will almost certainly be CR
> anyway.
>

As a compromise of sorts - would you be willing to propose some additional
text to go in section 11.5 that (maybe strongly) recommends the hash
function be collision resistant?

I'm envisioning the resultant 11.5 section saying that the hash function
MUST be second-preimage resistant and fully irreversible (as it does/will
now with slightly updated wording discussed below) but then also goes on to
say that it SHOULD just be collision resistant. I can come up with some
text recommending CR too but maybe not with the rationale/explanation as
you could.




> Preimage resistance maybe isn’t the term to use there. It’s used in that
> section-11.5
> 
> along with some text that says that it needs to be “infeasible to calculate
> the salt and claim value that result in a particular digest”.  We are
> trying to say that the hash has to have the property that it can’t be
> reversed (or even partially reversed, to your point). There’s probably a
> better way to state that the hash function has to be not at all reversible.
> Can you perhaps suggest some text? Or could we just replace “preimage
> resistant” with “irreversible” in that text in 11.5? And maybe qualify that
> text a bit more too with something like “infeasible to calculate the salt
> and claim value (or any portion thereof) that results in a particular
> digest”.
>
>
> That latter text seems a pretty good start to me. Part of the terminology
> problem I think is that SD-JWT is couched in terms of signatures but
> actually its primary security goal is confidentiality.
>

I'd push back a bit on that and argue that the primary security goal is
twofold and, as
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11
attempts to articulate, is about enabling confidentiality of selectively
disclosable content and ensuring the integrity (as issued) thereof. There
may still be some terminology difficulties :) But the primary security goal
is not just about confidentiality.



> As I said, I think the correct formal security notions come from the work
> on commitment schemes, which are “binding” and “hiding”. The hiding
> property is what you want here - it basically says that it’s infeasible for
> an attacker to learn anything about the message from the hash that they
> couldn’t already infer without the hash.
>
> The binding property is maybe too strong if we trust the issuer - it would
> require collision-resistance as I’ve said. There is a paper (
> https://eprint.iacr.org/2017/664) which distinguishes between
> “sender-binding” and “receiver-binding”, which sounds similar to what you
> want to express: trusted issuer, potentially untrusted holder/verifiers.
> However, I think the receiver binding notion is still too strong and would
> also require collision resistance. I’ll see if I can dig something up and
> suggest some wording.
>
> Your wording does look pretty good though so maybe we don’t need to be too
> formal about this?
>

Agree, I'm certainly okay going with that wording and not being too formal.
Will plan on making those updates.






> What I want to ensure is that a migration path like the following works:
>
> 1. at some future point in time the WG 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

On 25 Oct 2023, at 22:00, Brian Campbell  wrote:Thanks for the comments and questions Neil. With the help of the draft co-authors, I've tried to reply (probably inadequately!) inline below. Thanks. Some responses below. On Tue, Oct 24, 2023 at 3:48 AM Neil Madden  wrote:I’ve had a look through this new draft and I have some comments and questions. Some of which are similar to comments I already raised [1], but haven’t been addressed.Are we concerned about Holders and Issuers colluding?With SD-JWT or plain JWT or really any similar signed token construct the Verifier has to trust the Issuer ultimately to act/issue honestly. So colluding Holders and Issuers just isn't part of the threat model. I don't honestly know how that could be different. The Issuer, if malicious, can issue a token with whatever content they want.That’s reasonable.   For example, now that claim names are blinded an Issuer can add the same claim multiple times with different, potentially contradictory, values and then the Holder can selectively release one disclosure to one Verifier and a completely different one to another Verifier. This seems problematic at least, that the “same” credential could be interpreted differently by different parties.A well behaving Holder would reject such a credential based on the verification and processing rules (this one specifically). While malicious Issuers and colluding Holders and Issuers are outside the threat model for the reasons explained above. So this situation is handled as much as it can be (as best I know anyway) in the draft.A more sophisticated version of this “attack” illustrates the need for collision resistance in the hash function, not just preimage resistance as stated in the draft (and already raised by me in [1]). If the hash is not CR then a malicious Issuer can find colliding [salt, key, value] triplets that have the same hash value, give one to the Holder and then later claim that they actually signed the other one. (This is not just theoretical, similar attacks have been used to create fraudulent SSL certificates [2]).The draft currently says that second-preimage resistance is needed, which prevents a malicious Holder from finding a different Disclosure value that results in a digest that's the same as one in the signed credential. Protecting against a malicious user effectively forging or modifying disclosed claim names/values is the security objective. Second-preimage resistance is not as strong as collision resistance but I believe is correct and sufficient for the context of use. And a malicious Issuer isn't something that's in scope and could do all kinds of other bad things. This is the section of the security considerations with that: https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5Ok, that is a fair enough stance. Without requiring collision resistance though it does make SD-JWT a slightly weird signature scheme, in that the issuer is not actually committed to the contents of the token like they would be for a normal signed JWT. That is a surprising property. For example, if you store SD-JWTs for audit trail purposes (as some people do for normal JWTs), the contents are potentially repudiable. Like you say, if you trust the issuer then maybe that is fine, but it’s a sharp edge that maybe it would be better to remove? Given that pretty much any hash function that is likely to be used with SD-JWT will almost certainly be CR anyway.  This also indicates that the security strength of the signature scheme is bounded by the collision resistance of the hash function - e.g. there’s little point using ES512 with SHA-256, for example. Probably the security considerations should suggest matching hash functions to signature algorithms.Yeah, saying something about matching the strength of hash function and signature algorithm would probably be worthwhile. Yes, or just pick SHA-512…Furthermore, preimage resistance is not a sufficient property to ensure confidentiality of withheld claims. Preimage resistance holds if the attacker cannot recover the exact input that produced a given hash value, but it doesn’t preclude the attacker being able to recover partial information about that value. For example, consider the hash function H(x) = SHA-256(x) || x[x.len-10..x.len] (where || is concatenation). This hash function when applied to SD-JWT is preimage resistant (assuming the salt is strong), but leaks the last 10 bytes of the claim value.Preimage resistance maybe isn’t the term to use there. It’s used in that section-11.5 along with some text that says that it needs to be “infeasible to calculate the salt and claim value that result in a particular digest”.  We are trying to say that the hash has to have the property that it can’t be reversed (or even partially reversed, to your point). There’s probably a better way to state that the hash function has to be not at all reversible. Can you perhaps suggest some text? 

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

[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 internet-dra...@ietf.org:

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

--
Please use my new email address:m...@danielfett.de

___
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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Brian Campbell]

Thanks for the comments and questions Neil. With the help of the draft
co-authors, I've tried to reply (probably inadequately!) inline below.

On Tue, Oct 24, 2023 at 3:48 AM Neil Madden  wrote:

> I’ve had a look through this new draft and I have some comments and
> questions. Some of which are similar to comments I already raised [1], but
> haven’t been addressed.
>
> Are we concerned about Holders and Issuers colluding?
>

With SD-JWT or plain JWT or really any similar signed token construct the
Verifier has to trust the Issuer ultimately to act/issue honestly. So
colluding Holders and Issuers just isn't part of the threat model. I don't
honestly know how that could be different. The Issuer, if malicious, can
issue a token with whatever content they want.



> For example, now that claim names are blinded an Issuer can add the same
> claim multiple times with different, potentially contradictory, values and
> then the Holder can selectively release one disclosure to one Verifier and
> a completely different one to another Verifier. This seems problematic at
> least, that the “same” credential could be interpreted differently by
> different parties.
>

A well behaving Holder would reject such a credential based on the
verification and processing rules (this one specifically
).
While malicious Issuers and colluding Holders and Issuers are outside the
threat model for the reasons explained above. So this situation is handled
as much as it can be (as best I know anyway) in the draft.



A more sophisticated version of this “attack” illustrates the need for
> collision resistance in the hash function, not just preimage resistance as
> stated in the draft (and already raised by me in [1]). If the hash is not
> CR then a malicious Issuer can find colliding [salt, key, value] triplets
> that have the same hash value, give one to the Holder and then later claim
> that they actually signed the other one. (This is not just theoretical,
> similar attacks have been used to create fraudulent SSL certificates [2]).
>

The draft currently says that second-preimage resistance is needed, which
prevents a malicious Holder from finding a different Disclosure value that
results in a digest that's the same as one in the signed credential.
Protecting against a malicious user effectively forging or modifying
disclosed claim names/values is the security objective. Second-preimage
resistance is not as strong as collision resistance but I believe is
correct and sufficient for the context of use. And a malicious Issuer isn't
something that's in scope and could do all kinds of other bad things. This
is the section of the security considerations with that:
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html#section-11.5



> This also indicates that the security strength of the signature scheme is
> bounded by the collision resistance of the hash function - e.g. there’s
> little point using ES512 with SHA-256, for example. Probably the security
> considerations should suggest matching hash functions to signature
> algorithms.
>

Yeah, saying something about matching the strength of hash function and
signature algorithm would probably be worthwhile.


Furthermore, preimage resistance is not a sufficient property to ensure
> confidentiality of withheld claims. Preimage resistance holds if the
> attacker cannot recover the exact input that produced a given hash value,
> but it doesn’t preclude the attacker being able to recover partial
> information about that value. For example, consider the hash function H(x)
> = SHA-256(x) || x[x.len-10..x.len] (where || is concatenation). This hash
> function when applied to SD-JWT is preimage resistant (assuming the salt is
> strong), but leaks the last 10 bytes of the claim value.
>

Preimage resistance maybe isn’t the term to use there. It’s used in that
section-11.5

along with some text that says that it needs to be “infeasible to calculate
the salt and claim value that result in a particular digest”.  We are
trying to say that the hash has to have the property that it can’t be
reversed (or even partially reversed, to your point). There’s probably a
better way to state that the hash function has to be not at all reversible.
Can you perhaps suggest some text? Or could we just replace “preimage
resistant” with “irreversible” in that text in 11.5? And maybe qualify that
text a bit more too with something like “infeasible to calculate the salt
and claim value (or any portion thereof) that results in a particular
digest”.



> The appropriate security definition for SD-JWT is some form of
> cryptographic commitment scheme [3], with the associated security notions
> of hiding and binding. Honestly, I still think that this WG is not an
> appropriate venue for this 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Neil Madden]

I’ve had a look through this new draft and I have some comments and questions. 
Some of which are similar to comments I already raised [1], but haven’t been 
addressed.

Are we concerned about Holders and Issuers colluding? For example, now that 
claim names are blinded an Issuer can add the same claim multiple times with 
different, potentially contradictory, values and then the Holder can 
selectively release one disclosure to one Verifier and a completely different 
one to another Verifier. This seems problematic at least, that the “same” 
credential could be interpreted differently by different parties.

A more sophisticated version of this “attack” illustrates the need for 
collision resistance in the hash function, not just preimage resistance as 
stated in the draft (and already raised by me in [1]). If the hash is not CR 
then a malicious Issuer can find colliding [salt, key, value] triplets that 
have the same hash value, give one to the Holder and then later claim that they 
actually signed the other one. (This is not just theoretical, similar attacks 
have been used to create fraudulent SSL certificates [2]). This also indicates 
that the security strength of the signature scheme is bounded by the collision 
resistance of the hash function - e.g. there’s little point using ES512 with 
SHA-256, for example. Probably the security considerations should suggest 
matching hash functions to signature algorithms.

Furthermore, preimage resistance is not a sufficient property to ensure 
confidentiality of withheld claims. Preimage resistance holds if the attacker 
cannot recover the exact input that produced a given hash value, but it doesn’t 
preclude the attacker being able to recover partial information about that 
value. For example, consider the hash function H(x) = SHA-256(x) || 
x[x.len-10..x.len] (where || is concatenation). This hash function when applied 
to SD-JWT is preimage resistant (assuming the salt is strong), but leaks the 
last 10 bytes of the claim value.

The appropriate security definition for SD-JWT is some form of cryptographic 
commitment scheme [3], with the associated security notions of hiding and 
binding. Honestly, I still think that this WG is not an appropriate venue for 
this kind of novel (in the OAuth world) cryptographic scheme and external 
review by experts would be helpful.

All of this suggests that simply referring the the IANA hash function registry 
is not sufficient, as probably *most* of the entries there are not actually 
suitable for use in SD-JWT for one reason or another.

Some other comments:

The original JWT RFC [4] has this to say about the order of encryption and 
signatures:

   signatures over encrypted text are not considered valid in many
   jurisdictions.

Presumably the same argument holds about signatures over blinded values? That 
should perhaps be noted at least.

The draft repeatedly says that a symmetric signature algorithm (MAC) must not 
be used. Perhaps I’m missing something here, but why not? It doesn’t seem like 
it compromises any of the intended security properties. Use of a symmetric MAC 
may also limit the privacy impacts on users as it provides some measure of 
deniability (similar to that mentioned in section 12.1), as any Verifier in 
possession of the secret key could also have produced any claims that are 
subsequently leaked, allowing the user to deny that they were produced by the 
supposed Issuer. (This deniability property holds even without subsequent 
leaking of old signing keys).

The security considerations about salt entropy should probably reference RFC 
4086 (BCP 106) or something more up to date (maybe RFC 8937 too).

I think section 11.8 about selectively disclosing contraints on the use of a 
SD-JWT is completely inadequate and will almost certainly lead to attacks. 
Requiring Verifiers to hard-wire the set of constraints they enforce is likely 
to be damaging to future evolution of the standard as new security constraints 
are added. It would seem especially problematic to allow selective disclosure 
of a “cnf” claim for example, and yet nothing forbids it and the history of JWT 
usage suggests that anything not forbidden will at some point happen (and even 
some things that are forbidden). I suggest establishing a registry of claims 
that are really usage constraints and forbidding issuers from allowing anything 
in that list to be selectively-disclosed. (There are perhaps some exceptions 
here, e.g. “aud” is a constraint in this sense but it probably _does_ make 
sense for it to be selectively disclosed, but only on a per-array-item basis: 
that way a Holder cannot remove the constraint entirely but can still hide 
other “recipients”).

On a related note, section 11.6 says that to avoid this kind of attack, 
Verifiers MUST NOT take into account whether a Key Binding is present or not to 
decide whether to require Key Binding. This seems to preclude Verifiers that 
can handle different levels of access with 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Daniel Fett]

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 internet-dra...@ietf.org:

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


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth