Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[David Waite]

> On Feb 4, 2022, at 6:32 PM, Mike Jones 
>  wrote:
> 
> Kristina and I spoke about it today and we agreed that it makes sense to make 
> the hash algorithm explicit.  So for instance, we’d propose that the example
> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
> become
> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
> when using the SHA-256 hash function.
>  
> Similarly, we’d propose to also define S384, S512, and possibly also S3-256, 
> S3-384, and S3-512 (for the SHA-3 hash functions).

My ideal would be making the algorithm explicit in the name, while deferring 
establishing a registry of other algorithms until a technical need is 
established.

While it is not necessary that a URN namespace define a unique name for a 
resource, it is a useful property that would be lost with multiple hashing 
schemes. Use of a hashing scheme not supported by a piece of software would 
also mean that there is no way to verify the name corresponds to a given 
resource.

For this reason, if we do support multiple algorithms I would expect a mandate 
in dependent specs and systems that mandate a specific one or a specific set. 
For example, they may exclude the Kekkak variants (SHA3, SHAKE) as there are no 
other algorithms registered for JOSE which depend upon them.

>  
> For extra credit, if there’s already an IANA registry with string names for 
> these hash functions, we’d consider using it.  I looked for one and 
> surprisingly didn’t find it.  Or we could create one.
>  

The COSE algorithms are declared with both numbers and names, and include 
hashes as algorithms.

https://www.iana.org/assignments/cose/cose.xhtml#algorithms

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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Aaron Parecki]

That doesn't have the literal string "S256", only the full name.


On Fri, Feb 4, 2022 at 6:02 PM Brian Campbell  wrote:

> I think
> https://www.iana.org/assignments/named-information/named-information.xhtml
> maybe has what you're looking for.
>
> On Fri, Feb 4, 2022, 6:33 PM Mike Jones  40microsoft@dmarc.ietf.org> wrote:
>
>> Kristina and I spoke about it today and we agreed that it makes sense to
>> make the hash algorithm explicit.  So for instance, we’d propose that the
>> example
>>
>>
>> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>>
>> become
>>
>>
>> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>>
>> when using the SHA-256 hash function.
>>
>>
>>
>> Similarly, we’d propose to also define S384, S512, and possibly also
>> S3-256, S3-384, and S3-512 (for the SHA-3 hash functions).
>>
>>
>>
>> For extra credit, if there’s already an IANA registry with string names
>> for these hash functions, we’d consider using it.  I looked for one and
>> surprisingly didn’t find it.  Or we could create one.
>>
>>
>>
>>Thanks all,
>>
>>-- Mike & Kristina
>>
>>
>>
>> *From:* OAuth  *On Behalf Of * Mike Jones
>> *Sent:* Friday, February 4, 2022 7:30 AM
>> *To:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document
>>
>>
>>
>> Neil, thanks for your review.  First, you wrote:
>>
>>
>>
>> > Using a (hash of a) public key as an identifier is an idea that has
>> historically been subject to various attacks such as unknown key share
>> attacks, as well as issues due to malleable signature schemes or key
>> exchange schemes - where the same proof of identity is valid under many
>> public keys. The security considerations should mention these issues, and
>> potential suggest countermeasures (eg including the full public key JWK in
>> the input to be signed etc).
>>
>>
>>
>> I’m not all that familiar with the attacks you’re referencing.  Is there
>> I write-up on them that you could refer me and the other working group
>> members to so we can better understand them?  And ideally, could you write
>> up a paragraph or two on them that you’d like us to include in the Security
>> Considerations?
>>
>>
>>
>> Second, you asked that the hash algorithm be made explicit, as did
>> Vladimir.  I’ll consult with Kristina on that today and respond to that
>> suggestion in a subsequent message.
>>
>>
>>
>>Thanks again,
>>
>>-- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Vladimir Dzhuvinov
>> *Sent:* Thursday, February 3, 2022 11:00 PM
>> *To:* oauth@ietf.org
>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>>
>>
>>
>> The original JWK thumbprint RFC 7638 essentially describes the method for
>> composing the hash input from a JWK and that the output is base64url
>> encoded. SHA-256 is mentioned, but there is no default implied hash
>> function. This leaves it to applications / other specs to determine.
>>
>> https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4
>>
>> The URN gives us now a natural possibility to encode the hash function
>> alongside the fact that it's a JWK thumbprint, so let's include it. This
>> will make things more explicit and self-contained.
>>
>> What do the authors think about this possibility?
>>
>> ~Vladimir
>>
>> Vladimir Dzhuvinov
>>
>> On 04/02/2022 01:47, Neil Madden wrote:
>>
>> The draft doesn’t specify which hash function is being used. I assume it
>> is SHA-256, but it should either say that is the only algorithm allowed or
>> perhaps encode the hash algorithm into the URI. Otherwise the value is
>> ambiguous.
>>
>>
>>
>> Using a (hash of a) public key as an identifier is an idea that has
>> historically been subject to various attacks such as unknown key share
>> attacks, as well as issues due to malleable signature schemes or key
>> exchange schemes - where the same proof of identity is valid under many
>> public keys. The security considerations should mention these issues, and
>> potential suggest countermeasures (eg including the full public key JWK in
>> the input to be signed etc).
>>
>>
>>
>> — Neil
>>
>>
>>
>> On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
>>  wrote:
>>
>> 
>>
>> All,
>>
>>
>>
>> The *JWK Thumbprint URI *document is a simple and
>> straightforward specification.
>>
>>
>>
>> This is a WG Last Call for this document:
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
>>
>>
>>
>> Please, provide your feedback on the mailing list by *Feb 16th*.
>>
>>
>>
>> Regards,
>>
>>  Rifaat & Hannes
>>
>>
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> 

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Brian Campbell]

I think
https://www.iana.org/assignments/named-information/named-information.xhtml
maybe has what you're looking for.

On Fri, Feb 4, 2022, 6:33 PM Mike Jones  wrote:

> Kristina and I spoke about it today and we agreed that it makes sense to
> make the hash algorithm explicit.  So for instance, we’d propose that the
> example
>
>
> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>
> become
>
>
> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>
> when using the SHA-256 hash function.
>
>
>
> Similarly, we’d propose to also define S384, S512, and possibly also
> S3-256, S3-384, and S3-512 (for the SHA-3 hash functions).
>
>
>
> For extra credit, if there’s already an IANA registry with string names
> for these hash functions, we’d consider using it.  I looked for one and
> surprisingly didn’t find it.  Or we could create one.
>
>
>
>Thanks all,
>
>-- Mike & Kristina
>
>
>
> *From:* OAuth  *On Behalf Of * Mike Jones
> *Sent:* Friday, February 4, 2022 7:30 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document
>
>
>
> Neil, thanks for your review.  First, you wrote:
>
>
>
> > Using a (hash of a) public key as an identifier is an idea that has
> historically been subject to various attacks such as unknown key share
> attacks, as well as issues due to malleable signature schemes or key
> exchange schemes - where the same proof of identity is valid under many
> public keys. The security considerations should mention these issues, and
> potential suggest countermeasures (eg including the full public key JWK in
> the input to be signed etc).
>
>
>
> I’m not all that familiar with the attacks you’re referencing.  Is there I
> write-up on them that you could refer me and the other working group
> members to so we can better understand them?  And ideally, could you write
> up a paragraph or two on them that you’d like us to include in the Security
> Considerations?
>
>
>
> Second, you asked that the hash algorithm be made explicit, as did
> Vladimir.  I’ll consult with Kristina on that today and respond to that
> suggestion in a subsequent message.
>
>
>
>Thanks again,
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Vladimir Dzhuvinov
> *Sent:* Thursday, February 3, 2022 11:00 PM
> *To:* oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
>
>
> The original JWK thumbprint RFC 7638 essentially describes the method for
> composing the hash input from a JWK and that the output is base64url
> encoded. SHA-256 is mentioned, but there is no default implied hash
> function. This leaves it to applications / other specs to determine.
>
> https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4
>
> The URN gives us now a natural possibility to encode the hash function
> alongside the fact that it's a JWK thumbprint, so let's include it. This
> will make things more explicit and self-contained.
>
> What do the authors think about this possibility?
>
> ~Vladimir
>
> Vladimir Dzhuvinov
>
> On 04/02/2022 01:47, Neil Madden wrote:
>
> The draft doesn’t specify which hash function is being used. I assume it
> is SHA-256, but it should either say that is the only algorithm allowed or
> perhaps encode the hash algorithm into the URI. Otherwise the value is
> ambiguous.
>
>
>
> Using a (hash of a) public key as an identifier is an idea that has
> historically been subject to various attacks such as unknown key share
> attacks, as well as issues due to malleable signature schemes or key
> exchange schemes - where the same proof of identity is valid under many
> public keys. The security considerations should mention these issues, and
> potential suggest countermeasures (eg including the full public key JWK in
> the input to be signed etc).
>
>
>
> — Neil
>
>
>
> On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
>  wrote:
>
> 
>
> All,
>
>
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
>
>
> This is a WG Last Call for this document:
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
>
>
>
> Please, provide your feedback on the mailing list by *Feb 16th*.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
>
>
> ___
> 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
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material 

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Aaron Parecki]

I don't think this is actually the best place to reference, but S256
already exists in the registry established by RFC7636 (PKCE):

https://datatracker.ietf.org/doc/html/rfc7636#section-6.2
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#pkce-code-challenge-method

The other place these similar strings appear are FIDO, which also
references PKCE for the naming convention:

https://fidoalliance.org/specs/fido-v2.0-ps-20150904/fido-signature-format-v2.0-ps-20150904.html#iana-considerations

I thought I had remembered these strings being defined somewhere in NIST,
but I can't find that reference anymore.

Maybe it does make sense to establish this registry in the OAuth WG that
could be referenced by any related spec that needs them? OAuth 2.1 could
reference it as well.

Aaron



On Fri, Feb 4, 2022 at 5:33 PM Mike Jones  wrote:

> Kristina and I spoke about it today and we agreed that it makes sense to
> make the hash algorithm explicit.  So for instance, we’d propose that the
> example
>
>
> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>
> become
>
>
> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>
> when using the SHA-256 hash function.
>
>
>
> Similarly, we’d propose to also define S384, S512, and possibly also
> S3-256, S3-384, and S3-512 (for the SHA-3 hash functions).
>
>
>
> For extra credit, if there’s already an IANA registry with string names
> for these hash functions, we’d consider using it.  I looked for one and
> surprisingly didn’t find it.  Or we could create one.
>
>
>
>Thanks all,
>
>-- Mike & Kristina
>
>
>
> *From:* OAuth  *On Behalf Of * Mike Jones
> *Sent:* Friday, February 4, 2022 7:30 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document
>
>
>
> Neil, thanks for your review.  First, you wrote:
>
>
>
> > Using a (hash of a) public key as an identifier is an idea that has
> historically been subject to various attacks such as unknown key share
> attacks, as well as issues due to malleable signature schemes or key
> exchange schemes - where the same proof of identity is valid under many
> public keys. The security considerations should mention these issues, and
> potential suggest countermeasures (eg including the full public key JWK in
> the input to be signed etc).
>
>
>
> I’m not all that familiar with the attacks you’re referencing.  Is there I
> write-up on them that you could refer me and the other working group
> members to so we can better understand them?  And ideally, could you write
> up a paragraph or two on them that you’d like us to include in the Security
> Considerations?
>
>
>
> Second, you asked that the hash algorithm be made explicit, as did
> Vladimir.  I’ll consult with Kristina on that today and respond to that
> suggestion in a subsequent message.
>
>
>
>Thanks again,
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Vladimir Dzhuvinov
> *Sent:* Thursday, February 3, 2022 11:00 PM
> *To:* oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
>
>
> The original JWK thumbprint RFC 7638 essentially describes the method for
> composing the hash input from a JWK and that the output is base64url
> encoded. SHA-256 is mentioned, but there is no default implied hash
> function. This leaves it to applications / other specs to determine.
>
> https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4
>
> The URN gives us now a natural possibility to encode the hash function
> alongside the fact that it's a JWK thumbprint, so let's include it. This
> will make things more explicit and self-contained.
>
> What do the authors think about this possibility?
>
> ~Vladimir
>
> Vladimir Dzhuvinov
>
> On 04/02/2022 01:47, Neil Madden wrote:
>
> The draft doesn’t specify which hash function is being used. I assume it
> is SHA-256, but it should either say that is the only algorithm allowed or
> perhaps encode the hash algorithm into the URI. Otherwise the value is
> ambiguous.
>
>
>
> Using a (hash of a) public key as an identifier is an idea that has
> historically been subject to various attacks such as unknown key share
> attacks, as well as issues due to malleable signature schemes or key
> exchange schemes - where the same proof of identity is valid under many
> public keys. The security considerations should mention these issues, and
> potential suggest countermeasures (eg including the full public key JWK in
> the input to be signed etc).
>
>
>
> — Neil
>
>
>
> On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
>  wrote:
>
> 
>
> All,
>
>
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
>
>
> This is a WG Last Call for this document:
>
> 

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Mike Jones]

Kristina and I spoke about it today and we agreed that it makes sense to make 
the hash algorithm explicit.  So for instance, we’d propose that the example
urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
become
urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
when using the SHA-256 hash function.

Similarly, we’d propose to also define S384, S512, and possibly also S3-256, 
S3-384, and S3-512 (for the SHA-3 hash functions).

For extra credit, if there’s already an IANA registry with string names for 
these hash functions, we’d consider using it.  I looked for one and 
surprisingly didn’t find it.  Or we could create one.

   Thanks all,
   -- Mike & Kristina

From: OAuth  On Behalf Of Mike Jones
Sent: Friday, February 4, 2022 7:30 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document

Neil, thanks for your review.  First, you wrote:

> Using a (hash of a) public key as an identifier is an idea that has 
> historically been subject to various attacks such as unknown key share 
> attacks, as well as issues due to malleable signature schemes or key exchange 
> schemes - where the same proof of identity is valid under many public keys. 
> The security considerations should mention these issues, and potential 
> suggest countermeasures (eg including the full public key JWK in the input to 
> be signed etc).

I’m not all that familiar with the attacks you’re referencing.  Is there I 
write-up on them that you could refer me and the other working group members to 
so we can better understand them?  And ideally, could you write up a paragraph 
or two on them that you’d like us to include in the Security Considerations?

Second, you asked that the hash algorithm be made explicit, as did Vladimir.  
I’ll consult with Kristina on that today and respond to that suggestion in a 
subsequent message.

   Thanks again,
   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Vladimir Dzhuvinov
Sent: Thursday, February 3, 2022 11:00 PM
To: oauth@ietf.org
Subject: [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document


The original JWK thumbprint RFC 7638 essentially describes the method for 
composing the hash input from a JWK and that the output is base64url encoded. 
SHA-256 is mentioned, but there is no default implied hash function. This 
leaves it to applications / other specs to determine.

https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4

The URN gives us now a natural possibility to encode the hash function 
alongside the fact that it's a JWK thumbprint, so let's include it. This will 
make things more explicit and self-contained.

What do the authors think about this possibility?

~Vladimir

Vladimir Dzhuvinov
On 04/02/2022 01:47, Neil Madden wrote:
The draft doesn’t specify which hash function is being used. I assume it is 
SHA-256, but it should either say that is the only algorithm allowed or perhaps 
encode the hash algorithm into the URI. Otherwise the value is ambiguous.

Using a (hash of a) public key as an identifier is an idea that has 
historically been subject to various attacks such as unknown key share attacks, 
as well as issues due to malleable signature schemes or key exchange schemes - 
where the same proof of identity is valid under many public keys. The security 
considerations should mention these issues, and potential suggest 
countermeasures (eg including the full public key JWK in the input to be signed 
etc).

— Neil

On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
 wrote:

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes


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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Warren Parad]

I also agree that there hasn't been sufficient review of this document to
warrant progressing it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Fri, Feb 4, 2022 at 6:56 PM David Chadwick <
d.w.chadw...@verifiablecredentials.info> wrote:

> On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
>
> All,
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
> Actually this is a complex and inefficient specification compared to other
> possibilities.
>
> I have written an Internet-Draft outlining an alternative scheme, the JWK
> URI, which provides OIDC SIOPv2 with all the requirements that it needs
> with much less effort than implementing JWK Thumbprint URIs. I am currently
> formatting this I-D correctly to submit to the IETF. The rationale for this
> new Internet Draft is as follows.
>
> To produce or validate a JWK Thumbprint, both the sender and the receiver
> have to have the JWK available to them. Then they have to canonicalise the
> JWK as described in [RFC7638], and finally hash the octets of the UTF-8
> representation of this JSON object with a pre-agreed algorithm in order to
> both obtain the same hash value. The way that the JWK Thumbprint URI is
> used in SIOPv2 [SIOPv2] is as follows:
>
>1. the SIOP creates an asymmetric key pair and encodes the public key
>as a JWK
>2. the SIOP creates the JWK Thumbprint as described in [RFC7638] and
>converts it to a URI as described in [JONES],
>3. the SIOP passes both the JWK and JWK Thumbprint URI to the RP in
>the JWT,
>4. the RP extracts the JWK and JWK Thumbprint from the JWT
>5. the RP re-computes the JWK Thumbprint from the JWK
>6. the RP compares the computed JWK Thumbprint with the received JWK
>Thumbprint to confirm that they are equal.
>
> One can see that the use of JWK Thumbprint URIs is both inefficient (in
> all cases) and a significant disadvantage (in some cases). If the JWK URI
> is transferred instead of the JWK and JWK Thumbprint URI then:
>
> a) The SIOP will never need to create the JWK Thumbprint URI. The RP may
> only need to create the JWK Thumbprint if it needs this, for example, as a
> unique subject identifier. Even in this case, there is still an advantage
> to the RP in receiving the JWK URI instead of the JWK Thumprint URI, in
> that the RP no longer needs to pre-agree a hashing algorithm with the SIOP.
> Thus the RP can independently determine which hashing algorithm to use when
> creating its own JWK Thumbprint. (Note. If the SIOP were able to
> canonicalise the same public key in a JWK in different ways and produce
> different thumbprints from the same public key, then the canonicalisation
> algorithm is broken, and the RP would never to able to deterministically
> produce the same thumbprints each time.)
>
> b) In those cases where the SIOP uses ephemeral key pairs and a different
> public key each time it communicates with an RP, then neither party needs
> to produce the JWK Thumbprint as it will never be seen again. It is a
> significant disadvantage to have to use JWK Thumbprints in this case.
>
> I therefore kindly request that the JWK Thumbprint URI document does not
> progress until the WG has had chance to compare and contrast the two
> methods.
>
> Kind regards
>
> David
>
>
>
> This is a WG Last Call for this document:
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
>
> Please, provide your feedback on the mailing list by *Feb 16th*.
>
> Regards,
>  Rifaat & Hannes
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[David Chadwick]

  
  
On 02/02/2022 12:18, Rifaat Shekh-Yusef
  wrote:


  
  All,


The JWK Thumbprint URI document is a simple and
  straightforward specification.
  

Actually this is a complex and inefficient specification compared
  to other possibilities.
I have written an Internet-Draft outlining an alternative scheme,
  the JWK URI, which provides OIDC SIOPv2 with all the requirements
  that it needs with much less effort than implementing JWK
  Thumbprint URIs. I am currently formatting this I-D correctly to
  submit to the IETF. The rationale for this new Internet Draft is
  as follows.

To produce
  or validate a JWK Thumbprint, both the sender and the receiver
  have to have the JWK available to them. Then they have to
  canonicalise the JWK as described in [RFC7638], and finally
  hash the octets of the UTF-8 representation of this JSON
  object with a pre-agreed algorithm in order to both obtain the
  same hash value. The way that the JWK Thumbprint URI is used in
  SIOPv2 [SIOPv2] is as follows:

  the SIOP creates an asymmetric
key pair and encodes the public key as a JWK
  the SIOP creates
the JWK Thumbprint as described in [RFC7638] and converts it to
a URI as described in [JONES],
  the SIOP passes
both the JWK and JWK Thumbprint URI to the RP in the JWT,
  the RP extracts
the JWK and JWK Thumbprint from the JWT
  the RP re-computes
the JWK Thumbprint from the JWK
  the RP compares
the computed JWK Thumbprint with the received JWK Thumbprint to
confirm that they are equal. 

One can
  see that the use of JWK Thumbprint URIs is both inefficient (in
  all cases) and a significant disadvantage (in some cases). If the
  JWK URI is transferred instead of the JWK and JWK Thumbprint URI
  then:
a) The
  SIOP will never need to create the JWK Thumbprint URI. The RP may
  only need to create the JWK Thumbprint if it needs this, for
  example, as a unique subject identifier. Even in this case, there
  is still an advantage to the RP in receiving the JWK URI instead
  of the JWK Thumprint URI, in that the RP no longer needs to
  pre-agree a hashing algorithm with the SIOP. Thus the RP can
  independently determine which hashing algorithm to use when
  creating its own JWK Thumbprint. (Note. If the SIOP were able to
  canonicalise the same public key in a JWK in different ways and
  produce different thumbprints from the same public key, then the
  canonicalisation algorithm is broken, and the RP would never to
  able to deterministically produce the same thumbprints each time.)
b) In
  those cases where the SIOP uses ephemeral key pairs and a
  different public key each time it communicates with an RP, then
  neither party needs to produce the JWK Thumbprint as it will never
  be seen again. It is a significant disadvantage to have to use JWK
  Thumbprints in this case.
I therefore kindly request that the JWK Thumbprint URI document
  does not progress until the WG has had chance to compare and
  contrast the two methods.
Kind regards
David



  


This is a WG Last Call for this document:

https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html



Please, provide your feedback on the mailing list by Feb
16th.


Regards,
 Rifaat & Hannes




  
  
  
  ___
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] [EXTERNAL] Re: WGLC for JWK Thumbprint URI document

[Mike Jones]

Neil, thanks for your review.  First, you wrote:

> Using a (hash of a) public key as an identifier is an idea that has 
> historically been subject to various attacks such as unknown key share 
> attacks, as well as issues due to malleable signature schemes or key exchange 
> schemes - where the same proof of identity is valid under many public keys. 
> The security considerations should mention these issues, and potential 
> suggest countermeasures (eg including the full public key JWK in the input to 
> be signed etc).

I’m not all that familiar with the attacks you’re referencing.  Is there I 
write-up on them that you could refer me and the other working group members to 
so we can better understand them?  And ideally, could you write up a paragraph 
or two on them that you’d like us to include in the Security Considerations?

Second, you asked that the hash algorithm be made explicit, as did Vladimir.  
I’ll consult with Kristina on that today and respond to that suggestion in a 
subsequent message.

   Thanks again,
   -- Mike

From: OAuth  On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 3, 2022 11:00 PM
To: oauth@ietf.org
Subject: [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document


The original JWK thumbprint RFC 7638 essentially describes the method for 
composing the hash input from a JWK and that the output is base64url encoded. 
SHA-256 is mentioned, but there is no default implied hash function. This 
leaves it to applications / other specs to determine.

https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4

The URN gives us now a natural possibility to encode the hash function 
alongside the fact that it's a JWK thumbprint, so let's include it. This will 
make things more explicit and self-contained.

What do the authors think about this possibility?

~Vladimir

Vladimir Dzhuvinov
On 04/02/2022 01:47, Neil Madden wrote:
The draft doesn’t specify which hash function is being used. I assume it is 
SHA-256, but it should either say that is the only algorithm allowed or perhaps 
encode the hash algorithm into the URI. Otherwise the value is ambiguous.

Using a (hash of a) public key as an identifier is an idea that has 
historically been subject to various attacks such as unknown key share attacks, 
as well as issues due to malleable signature schemes or key exchange schemes - 
where the same proof of identity is valid under many public keys. The security 
considerations should mention these issues, and potential suggest 
countermeasures (eg including the full public key JWK in the input to be signed 
etc).

— Neil


On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
 wrote:

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes


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

Re: [OAUTH-WG] OAuth 2.1: Missing token?

[Neil Madden]

The example at the end of section 5.2.2 suggests no error_code and just a 
401/WWW-Authenticate header in this case:

 For example, in response to a protected resource request without
   authentication:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: Bearer realm="example"


And the paragraph in section 5.2.3 immediately following the section you quote 
is even more explicit:

   If the request lacks any authentication information (e.g., the client
   was unaware that authentication is necessary or attempted using an
   unsupported authentication method), the resource server SHOULD NOT
   include an error code or other error information.

So, no error_code at all if no access token supplied.

Kind regards,

Neil

> On 4 Feb 2022, at 09:15, Johannes Koch 
>  wrote:
> 
>   EntSec couldn't recognize this email as this is the first time you 
> received an email from this sender johannes.koch=40avenga.com @ dmarc.ietf.org
> 
> Hi there,
> 
> a question about 
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04 
> 
> 5.2.3.  Error Codes
> 
>"invalid_request":  The request is missing a required parameter,
>   includes an unsupported parameter or parameter value, repeats the
>   same parameter, uses more than one method for including an access
>   token, or is otherwise malformed.  The resource server SHOULD
>   respond with the HTTP 400 (Bad Request) status code.
> 
>"invalid_token":  The access token provided is expired, revoked,
>   malformed, or invalid for other reasons.  The resource SHOULD
>   respond with the HTTP 401 (Unauthorized) status code.  The client
>   MAY request a new access token and retry the protected resource
>   request.
> 
> Now, what is the intended error code for the situation where no access token 
> is provided? The description for invalid_token seems to imply that one token 
> was provided.
> As the token may be seen as a required parameter, invalid_request may be 
> appropriate. However, a missing token smells more like HTTP 401 
> (Unauthorized).
> 
> Should this be an additional error code (missing_token)? Or should this case 
> be added to invalid_token?
> 
> -- 
> Johannes Koch
> ___
> 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] OAuth 2.1: Missing token?

[Warren Parad]

It may help to specifically clarify which interaction with the AS are we
talking about here.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Fri, Feb 4, 2022 at 10:16 AM Johannes Koch  wrote:

> Hi there,
>
> a question about
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04
>
> 5.2.3.  Error Codes
>
>"invalid_request":  The request is missing a required parameter,
>   includes an unsupported parameter or parameter value, repeats the
>   same parameter, uses more than one method for including an access
>   token, or is otherwise malformed.  The resource server SHOULD
>   respond with the HTTP 400 (Bad Request) status code.
>
>"invalid_token":  The access token provided is expired, revoked,
>   malformed, or invalid for other reasons.  The resource SHOULD
>   respond with the HTTP 401 (Unauthorized) status code.  The client
>   MAY request a new access token and retry the protected resource
>   request.
>
> Now, what is the intended error code for the situation where no access
> token is provided? The description for invalid_token seems to imply that
> one token was provided.
> As the token may be seen as a required parameter, invalid_request may be
> appropriate. However, a missing token smells more like HTTP 401
> (Unauthorized).
>
> Should this be an additional error code (missing_token)? Or should this
> case be added to invalid_token?
>
> --
> Johannes Koch
> ___
> 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

[OAUTH-WG] OAuth 2.1: Missing token?

[Johannes Koch]

Hi there,

a question about
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04

5.2.3.  Error Codes

   "invalid_request":  The request is missing a required parameter,
  includes an unsupported parameter or parameter value, repeats the
  same parameter, uses more than one method for including an access
  token, or is otherwise malformed.  The resource server SHOULD
  respond with the HTTP 400 (Bad Request) status code.

   "invalid_token":  The access token provided is expired, revoked,
  malformed, or invalid for other reasons.  The resource SHOULD
  respond with the HTTP 401 (Unauthorized) status code.  The client
  MAY request a new access token and retry the protected resource
  request.

Now, what is the intended error code for the situation where no access
token is provided? The description for invalid_token seems to imply that
one token was provided.
As the token may be seen as a required parameter, invalid_request may be
appropriate. However, a missing token smells more like HTTP 401
(Unauthorized).

Should this be an additional error code (missing_token)? Or should this
case be added to invalid_token?

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