Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Brian Campbell]

The tl;dr is that I believe Neil's suggestion is of sufficient merit to
warrant seriously considering making the change.

That was more words than it needed to be too. But maybe clarifies.

On Tue, Sep 15, 2020 at 4:51 PM Dick Hardt  wrote:

> That was a lot of words Brian. What is the "tl;dr:"? (I read it, but I'm
> not sure where you landed given your last sentence)
> ᐧ
>
> On Tue, Sep 15, 2020 at 3:16 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> Sorry for the slow reply to this one, Neil. It's gotten me thinking a bit
>> and it took some time to gather my thoughts and attempt to articulate them.
>>
>> It is true that, as defined in the current -01 draft, there is the
>> additional step for the RS to check that the proof key matches the hash in
>> the AT. But I think that equating it to "exactly" that kind of
>> CVE-2018-0114 mistake or Moxie’s Cryptographic Doom Principle is a
>> significant mischaracterization. The DPoP proof message and its signature
>> are used to establish that the sender holds the corresponding private key.
>> Then binding tokens to that key or checking such bindings can be done.
>> That's quite different from checking the signature/integrity of a message
>> against a trusted key before relying on the content of the message, which
>> is what CVE-2018-0114 and erroneously trusting the key is about. I'm
>> admittedly a little touchy about this because I tried to speak up about the
>> potential problems with blindly trusting the jwk header back in the days of
>> developing the JOSE specs. And have even joked more recently that the DPoP
>> proof finally uncovered a legitimate use for it. So with all that said, I
>> don't think it rises to the level of doom. And the step of checking the
>> binding of the token to the proof key is pretty fundamental. It's
>> conceptually the same as how the AT binding is done with MTLS / RFC 8705
>> and the expired/defunct draft-ietf-oauth-token-binding. That doesn't make
>> it right per se but there's some precedent for the general approach.
>> Following that conceptual precedent was part of the motivation for the
>> current approach - not so much as simplicity for the client but simplicity
>> in the form of consistency in the protocol definition itself. But maybe
>> that motivation was too much so as the hash based cnf binding is kinda
>> necessary in those that are doing the key proof at or closer to the
>> transport layer but DPoP has all the stuff at the same layer so could do it
>> differently. Putting the jwk in the cnf of the AT would eliminate the
>> possibility of resource servers forgetting to check the binding. Of course
>> there are still mistakes that could be made but removing even the
>> possibility of that particular one is compelling.
>>
>> The efficiency gains you mention are dependent on circumstance and not
>> always applicable, as you've kinda alluded to. The many variations of
>> deployment options (e.g., reference vs self-contained tokens, introspection
>> vs. local validation and either with various caching strategies, location
>> of entities and communication path between them) make quantifying it rather
>> difficult and circumstantially dependent. However, moving the jwk from the
>> DPoP proof to the AT (by value or reference) would reduce the overall
>> amount of data that is conveyed across the two items from a jwk and its
>> hash to just the jwk. That's not a huge gain but it is more than nothing.
>> It would also eliminate the need to codify a hash function for the jwk
>> thumbprint, which admittedly would be rather nice.
>>
>> I guess that's a lot of words to try and kinda defend the current
>> approach while also admitting that I'm coming around to seeing the light in
>> your suggestion.
>>
>> On Wed, Sep 9, 2020 at 12:43 AM Neil Madden 
>> wrote:
>>
>>> I disagree with this rationale, I’m afraid. I don’t think the simplicity
>>> gain for the client is really very great and I think we will regret this
>>> decision.
>>>
>>> Most importantly, including the JWK directly in the proof token
>>> increases the likelihood that somebody will just validate the signature
>>> using that key and fail to check that it matches the hash in the AT. We’ve
>>> already seen at least one vendor make exactly this kind of mistake in the
>>> past [1]. Letting the proof tell you the key to use to verify the proof is
>>> another example of Moxie’s Cryptographic Doom Principle [2] - trusting the
>>> message before you’ve authenticated it.
>>>
>>> Moving the jwk from the DPoP proof to the AT/introspection response
>>> reduces the chances of these kind of mistakes.
>>>
>>> As a bonus it also has efficiency gains because the size of the DPoP
>>> proof is reduced - potentially by a lot for RSA keys. Although the JWK
>>> still has to be communicated to the RS, this can be more efficient because:
>>> - For token introspection, in many deployments the introspection request
>>> will be within a datacenter and so over a high-bandwidth 

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Dick Hardt]

That was a lot of words Brian. What is the "tl;dr:"? (I read it, but I'm
not sure where you landed given your last sentence)
ᐧ

On Tue, Sep 15, 2020 at 3:16 PM Brian Campbell  wrote:

> Sorry for the slow reply to this one, Neil. It's gotten me thinking a bit
> and it took some time to gather my thoughts and attempt to articulate them.
>
> It is true that, as defined in the current -01 draft, there is the
> additional step for the RS to check that the proof key matches the hash in
> the AT. But I think that equating it to "exactly" that kind of
> CVE-2018-0114 mistake or Moxie’s Cryptographic Doom Principle is a
> significant mischaracterization. The DPoP proof message and its signature
> are used to establish that the sender holds the corresponding private key.
> Then binding tokens to that key or checking such bindings can be done.
> That's quite different from checking the signature/integrity of a message
> against a trusted key before relying on the content of the message, which
> is what CVE-2018-0114 and erroneously trusting the key is about. I'm
> admittedly a little touchy about this because I tried to speak up about the
> potential problems with blindly trusting the jwk header back in the days of
> developing the JOSE specs. And have even joked more recently that the DPoP
> proof finally uncovered a legitimate use for it. So with all that said, I
> don't think it rises to the level of doom. And the step of checking the
> binding of the token to the proof key is pretty fundamental. It's
> conceptually the same as how the AT binding is done with MTLS / RFC 8705
> and the expired/defunct draft-ietf-oauth-token-binding. That doesn't make
> it right per se but there's some precedent for the general approach.
> Following that conceptual precedent was part of the motivation for the
> current approach - not so much as simplicity for the client but simplicity
> in the form of consistency in the protocol definition itself. But maybe
> that motivation was too much so as the hash based cnf binding is kinda
> necessary in those that are doing the key proof at or closer to the
> transport layer but DPoP has all the stuff at the same layer so could do it
> differently. Putting the jwk in the cnf of the AT would eliminate the
> possibility of resource servers forgetting to check the binding. Of course
> there are still mistakes that could be made but removing even the
> possibility of that particular one is compelling.
>
> The efficiency gains you mention are dependent on circumstance and not
> always applicable, as you've kinda alluded to. The many variations of
> deployment options (e.g., reference vs self-contained tokens, introspection
> vs. local validation and either with various caching strategies, location
> of entities and communication path between them) make quantifying it rather
> difficult and circumstantially dependent. However, moving the jwk from the
> DPoP proof to the AT (by value or reference) would reduce the overall
> amount of data that is conveyed across the two items from a jwk and its
> hash to just the jwk. That's not a huge gain but it is more than nothing.
> It would also eliminate the need to codify a hash function for the jwk
> thumbprint, which admittedly would be rather nice.
>
> I guess that's a lot of words to try and kinda defend the current approach
> while also admitting that I'm coming around to seeing the light in your
> suggestion.
>
> On Wed, Sep 9, 2020 at 12:43 AM Neil Madden 
> wrote:
>
>> I disagree with this rationale, I’m afraid. I don’t think the simplicity
>> gain for the client is really very great and I think we will regret this
>> decision.
>>
>> Most importantly, including the JWK directly in the proof token increases
>> the likelihood that somebody will just validate the signature using that
>> key and fail to check that it matches the hash in the AT. We’ve already
>> seen at least one vendor make exactly this kind of mistake in the past [1].
>> Letting the proof tell you the key to use to verify the proof is another
>> example of Moxie’s Cryptographic Doom Principle [2] - trusting the message
>> before you’ve authenticated it.
>>
>> Moving the jwk from the DPoP proof to the AT/introspection response
>> reduces the chances of these kind of mistakes.
>>
>> As a bonus it also has efficiency gains because the size of the DPoP
>> proof is reduced - potentially by a lot for RSA keys. Although the JWK
>> still has to be communicated to the RS, this can be more efficient because:
>> - For token introspection, in many deployments the introspection request
>> will be within a datacenter and so over a high-bandwidth low-latency
>> network. This is usually not the case for the DPoP proof, which may be over
>> a poor mobile connection.
>> - For embedded directly in a JWT access token, the JWK will be in the
>> claims rather than the header and so can at least be compressed. (Albeit
>> not by much, because public keys don’t compress well, but the rest of the
>> AT will 

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Brian Campbell]

Sorry for the slow reply to this one, Neil. It's gotten me thinking a bit
and it took some time to gather my thoughts and attempt to articulate them.

It is true that, as defined in the current -01 draft, there is the
additional step for the RS to check that the proof key matches the hash in
the AT. But I think that equating it to "exactly" that kind of
CVE-2018-0114 mistake or Moxie’s Cryptographic Doom Principle is a
significant mischaracterization. The DPoP proof message and its signature
are used to establish that the sender holds the corresponding private key.
Then binding tokens to that key or checking such bindings can be done.
That's quite different from checking the signature/integrity of a message
against a trusted key before relying on the content of the message, which
is what CVE-2018-0114 and erroneously trusting the key is about. I'm
admittedly a little touchy about this because I tried to speak up about the
potential problems with blindly trusting the jwk header back in the days of
developing the JOSE specs. And have even joked more recently that the DPoP
proof finally uncovered a legitimate use for it. So with all that said, I
don't think it rises to the level of doom. And the step of checking the
binding of the token to the proof key is pretty fundamental. It's
conceptually the same as how the AT binding is done with MTLS / RFC 8705
and the expired/defunct draft-ietf-oauth-token-binding. That doesn't make
it right per se but there's some precedent for the general approach.
Following that conceptual precedent was part of the motivation for the
current approach - not so much as simplicity for the client but simplicity
in the form of consistency in the protocol definition itself. But maybe
that motivation was too much so as the hash based cnf binding is kinda
necessary in those that are doing the key proof at or closer to the
transport layer but DPoP has all the stuff at the same layer so could do it
differently. Putting the jwk in the cnf of the AT would eliminate the
possibility of resource servers forgetting to check the binding. Of course
there are still mistakes that could be made but removing even the
possibility of that particular one is compelling.

The efficiency gains you mention are dependent on circumstance and not
always applicable, as you've kinda alluded to. The many variations of
deployment options (e.g., reference vs self-contained tokens, introspection
vs. local validation and either with various caching strategies, location
of entities and communication path between them) make quantifying it rather
difficult and circumstantially dependent. However, moving the jwk from the
DPoP proof to the AT (by value or reference) would reduce the overall
amount of data that is conveyed across the two items from a jwk and its
hash to just the jwk. That's not a huge gain but it is more than nothing.
It would also eliminate the need to codify a hash function for the jwk
thumbprint, which admittedly would be rather nice.

I guess that's a lot of words to try and kinda defend the current approach
while also admitting that I'm coming around to seeing the light in your
suggestion.

On Wed, Sep 9, 2020 at 12:43 AM Neil Madden 
wrote:

> I disagree with this rationale, I’m afraid. I don’t think the simplicity
> gain for the client is really very great and I think we will regret this
> decision.
>
> Most importantly, including the JWK directly in the proof token increases
> the likelihood that somebody will just validate the signature using that
> key and fail to check that it matches the hash in the AT. We’ve already
> seen at least one vendor make exactly this kind of mistake in the past [1].
> Letting the proof tell you the key to use to verify the proof is another
> example of Moxie’s Cryptographic Doom Principle [2] - trusting the message
> before you’ve authenticated it.
>
> Moving the jwk from the DPoP proof to the AT/introspection response
> reduces the chances of these kind of mistakes.
>
> As a bonus it also has efficiency gains because the size of the DPoP proof
> is reduced - potentially by a lot for RSA keys. Although the JWK still has
> to be communicated to the RS, this can be more efficient because:
> - For token introspection, in many deployments the introspection request
> will be within a datacenter and so over a high-bandwidth low-latency
> network. This is usually not the case for the DPoP proof, which may be over
> a poor mobile connection.
> - For embedded directly in a JWT access token, the JWK will be in the
> claims rather than the header and so can at least be compressed. (Albeit
> not by much, because public keys don’t compress well, but the rest of the
> AT will and that can compensate a little for the extra bulk).
>
> [1]: https://nvd.nist.gov/vuln/detail/CVE-2018-0114
> [2]: https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html
>
> — Neil
>
> On 8 Sep 2020, at 23:46, Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
> 
> Indeed there are 

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[toshio9.ito]

Hi Brian,

Thanks for clarification. Now I understand the rationale of this design.

I agree that having many options leads to interoperability issues and security
risk. Also, I forgot about public clients. I think requiring "jwk" in DPoP Proof
is one way to cover all use cases.



From: Brian Campbell 
Sent: Wednesday, September 9, 2020 7:45 AM
To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) 
Cc: oauth 
Subject: Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

Indeed there are cases, as you point out, where the key might be knowable to 
the server via some other means, which makes the "jwk" header in the DPoP proof 
not strictly necessary. And while omitting the key in such cases would reduce 
the size of some messages (the DPoP proof anyway), such optionality would add 
complexity to implementations and deployments (and that kind of complexity can 
and often does degrade interoperability and even security). How, for example, 
would a client know if the access token includes the public key and thus 
whether or not to include the key with the proof? Sure the access token could 
always include the key (rather than thumbprint) but then there's the question 
of how to get the key to the AS. As well as the stated desire to utilize the 
same DPoP Proof structure for requests to both the AS and RS. There will be 
some clients that have public key(s) registered and some that won't (maybe a 
lot that won't as a driving use case for many for this is key binding access 
and refresh tokens for public clients). The protocol defined by the draft needs 
to account for both.

Ultimately there are a number of different ways the necessary data could flow 
through the various protocol elements. And there are some tradeoffs with 
different approaches and/or trying to accommodate variations under one 
approach. The approach the draft has taken thus far is to prioritize 
consistency and simplicity as much as is possible. And that ethos has led to 
how it's currently defined, which is to always include the key in the proof and 
bind to a hash of the key in the access token.


On Tue, Sep 8, 2020 at 3:29 AM 
mailto:toshio9@toshiba.co.jp>> wrote:
Hi all,

In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
REQUIRED. However, there are some cases where "jwk" is not necessary in theory.

For example, consider a case where the client is registered with the
Authorization Server, and its one and only public key is also registered with
the AS. In that case, when the AS receives a request on Token endpoint, it can
just use the public key registered for the client to verify the DPoP Proof.
There is no need to send the public key in DPoP Proof.

The same goes for requests to the Resource Server, if the AS and RS share the
storage for clients' public keys. Things are a little difficult if the AS and RS
are separate. Probably the Access Token or its introspection result have to
include the public key (instead of its thumbprint as described in section 7).

If the client registers multiple keys with the AS, it needs to specify which key
it uses to sign the DPoP Proof. However, there is still no absolute need to send
the whole key in DPoP Proof. Instead, the client could use "kid" header
parameter to specify the key.

Daniel Fett once mentioned the above case in the GitHub issue #26 [*1], but I'm
not sure what happened to the discussion. There was also a comment on the latest
draft about the "jwk" header parameter [*2]. I agree with using the same DPoP
Proof structure for requests to AS and RS, but I think there are some cases
where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would allow
those cases to reduce some messaging overhead.

I'd like to hear your opinions about it.


[*1]: https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
[*2]: https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/


Best regards,
Toshio Ito

-
Toshio Ito
Research and Development Center
Toshiba Corporation

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

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] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[toshio9.ito]

Hi Takahiro,

Thanks for pointing out. I forgot that OAuth2 client registration is basically
for a client application, not for a client instance. As you said, if we omit
"jwk" altogether and rely on client authentication to identify the signing key,
all instances of the client have to use the same key. That would be bad.



From: Takahiko Kawasaki 
Sent: Tuesday, September 8, 2020 11:23 PM
To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) 
Cc: oauth 
Subject: Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

To enable each "instance" of a client application to use a key pair which is 
dedicated to the instance, the public key needs to be included in the DPoP 
proof. On the other hand, in the scenario you described, all instances of the 
client application have to share one key pair. If client application instances 
don't have to share one key pair, it's better.

Illustrated DPoP (OAuth Access Token Security Enhancement)
https://medium.com/@darutk/illustrated-dpop-oauth-access-token-security-enhancement-801680d761ff

Best Regards,
Takahiko Kawasaki

On Tue, Sep 8, 2020 at 6:29 PM 
mailto:toshio9@toshiba.co.jp>> wrote:
Hi all,

In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
REQUIRED. However, there are some cases where "jwk" is not necessary in theory.

For example, consider a case where the client is registered with the
Authorization Server, and its one and only public key is also registered with
the AS. In that case, when the AS receives a request on Token endpoint, it can
just use the public key registered for the client to verify the DPoP Proof.
There is no need to send the public key in DPoP Proof.

The same goes for requests to the Resource Server, if the AS and RS share the
storage for clients' public keys. Things are a little difficult if the AS and RS
are separate. Probably the Access Token or its introspection result have to
include the public key (instead of its thumbprint as described in section 7).

If the client registers multiple keys with the AS, it needs to specify which key
it uses to sign the DPoP Proof. However, there is still no absolute need to send
the whole key in DPoP Proof. Instead, the client could use "kid" header
parameter to specify the key.

Daniel Fett once mentioned the above case in the GitHub issue #26 [*1], but I'm
not sure what happened to the discussion. There was also a comment on the latest
draft about the "jwk" header parameter [*2]. I agree with using the same DPoP
Proof structure for requests to AS and RS, but I think there are some cases
where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would allow
those cases to reduce some messaging overhead.

I'd like to hear your opinions about it.


[*1]: https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
[*2]: https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/


Best regards,
Toshio Ito

-
Toshio Ito
Research and Development Center
Toshiba Corporation

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

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Filip Skokan]

+1 for keeping it simple. The design itself promotes unique-per-instance
keys, not pre-registration.

S pozdravem,
*Filip Skokan*


On Wed, 9 Sep 2020 at 00:46, Brian Campbell  wrote:

> Indeed there are cases, as you point out, where the key might be knowable
> to the server via some other means, which makes the "jwk" header in the
> DPoP proof not strictly necessary. And while omitting the key in such cases
> would reduce the size of some messages (the DPoP proof anyway), such
> optionality would add complexity to implementations and deployments (and
> that kind of complexity can and often does degrade interoperability and
> even security). How, for example, would a client know if the access token
> includes the public key and thus whether or not to include the key with the
> proof? Sure the access token could always include the key (rather than
> thumbprint) but then there's the question of how to get the key to the AS.
> As well as the stated desire to utilize the same DPoP Proof structure for
> requests to both the AS and RS. There will be some clients that have public
> key(s) registered and some that won't (maybe a lot that won't as a driving
> use case for many for this is key binding access and refresh tokens for
> public clients). The protocol defined by the draft needs to account for
> both.
>
> Ultimately there are a number of different ways the necessary data could
> flow through the various protocol elements. And there are some tradeoffs
> with different approaches and/or trying to accommodate variations under one
> approach. The approach the draft has taken thus far is to prioritize
> consistency and simplicity as much as is possible. And that ethos has led
> to how it's currently defined, which is to always include the key in the
> proof and bind to a hash of the key in the access token.
>
>
> On Tue, Sep 8, 2020 at 3:29 AM  wrote:
>
>> Hi all,
>>
>> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
>> REQUIRED. However, there are some cases where "jwk" is not necessary in
>> theory.
>>
>> For example, consider a case where the client is registered with the
>> Authorization Server, and its one and only public key is also registered
>> with
>> the AS. In that case, when the AS receives a request on Token endpoint,
>> it can
>> just use the public key registered for the client to verify the DPoP
>> Proof.
>> There is no need to send the public key in DPoP Proof.
>>
>> The same goes for requests to the Resource Server, if the AS and RS share
>> the
>> storage for clients' public keys. Things are a little difficult if the AS
>> and RS
>> are separate. Probably the Access Token or its introspection result have
>> to
>> include the public key (instead of its thumbprint as described in section
>> 7).
>>
>> If the client registers multiple keys with the AS, it needs to specify
>> which key
>> it uses to sign the DPoP Proof. However, there is still no absolute need
>> to send
>> the whole key in DPoP Proof. Instead, the client could use "kid" header
>> parameter to specify the key.
>>
>> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1],
>> but I'm
>> not sure what happened to the discussion. There was also a comment on the
>> latest
>> draft about the "jwk" header parameter [*2]. I agree with using the same
>> DPoP
>> Proof structure for requests to AS and RS, but I think there are some
>> cases
>> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would
>> allow
>> those cases to reduce some messaging overhead.
>>
>> I'd like to hear your opinions about it.
>>
>>
>> [*1]:
>> https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
>> [*2]:
>> https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/
>>
>>
>> Best regards,
>> Toshio Ito
>>
>> -
>> Toshio Ito
>> Research and Development Center
>> Toshiba Corporation
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Neil Madden]

I disagree with this rationale, I’m afraid. I don’t think the simplicity gain 
for the client is really very great and I think we will regret this decision.

Most importantly, including the JWK directly in the proof token increases the 
likelihood that somebody will just validate the signature using that key and 
fail to check that it matches the hash in the AT. We’ve already seen at least 
one vendor make exactly this kind of mistake in the past [1]. Letting the proof 
tell you the key to use to verify the proof is another example of Moxie’s 
Cryptographic Doom Principle [2] - trusting the message before you’ve 
authenticated it. 

Moving the jwk from the DPoP proof to the AT/introspection response reduces the 
chances of these kind of mistakes. 

As a bonus it also has efficiency gains because the size of the DPoP proof is 
reduced - potentially by a lot for RSA keys. Although the JWK still has to be 
communicated to the RS, this can be more efficient because:
- For token introspection, in many deployments the introspection request will 
be within a datacenter and so over a high-bandwidth low-latency network. This 
is usually not the case for the DPoP proof, which may be over a poor mobile 
connection. 
- For embedded directly in a JWT access token, the JWK will be in the claims 
rather than the header and so can at least be compressed. (Albeit not by much, 
because public keys don’t compress well, but the rest of the AT will and that 
can compensate a little for the extra bulk). 

[1]: https://nvd.nist.gov/vuln/detail/CVE-2018-0114
[2]: https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html

— Neil

>> On 8 Sep 2020, at 23:46, Brian Campbell 
>>  wrote:
> 
> Indeed there are cases, as you point out, where the key might be knowable to 
> the server via some other means, which makes the "jwk" header in the DPoP 
> proof not strictly necessary. And while omitting the key in such cases would 
> reduce the size of some messages (the DPoP proof anyway), such optionality 
> would add complexity to implementations and deployments (and that kind of 
> complexity can and often does degrade interoperability and even security). 
> How, for example, would a client know if the access token includes the public 
> key and thus whether or not to include the key with the proof? Sure the 
> access token could always include the key (rather than thumbprint) but then 
> there's the question of how to get the key to the AS. As well as the stated 
> desire to utilize the same DPoP Proof structure for requests to both the AS 
> and RS. There will be some clients that have public key(s) registered and 
> some that won't (maybe a lot that won't as a driving use case for many for 
> this is key binding access and refresh tokens for public clients). The 
> protocol defined by the draft needs to account for both. 
> 
> Ultimately there are a number of different ways the necessary data could flow 
> through the various protocol elements. And there are some tradeoffs with 
> different approaches and/or trying to accommodate variations under one 
> approach. The approach the draft has taken thus far is to prioritize 
> consistency and simplicity as much as is possible. And that ethos has led to 
> how it's currently defined, which is to always include the key in the proof 
> and bind to a hash of the key in the access token. 
> 
> 
>> On Tue, Sep 8, 2020 at 3:29 AM  wrote:
>> Hi all,
>> 
>> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
>> REQUIRED. However, there are some cases where "jwk" is not necessary in 
>> theory.
>> 
>> For example, consider a case where the client is registered with the
>> Authorization Server, and its one and only public key is also registered with
>> the AS. In that case, when the AS receives a request on Token endpoint, it 
>> can
>> just use the public key registered for the client to verify the DPoP Proof.
>> There is no need to send the public key in DPoP Proof.
>> 
>> The same goes for requests to the Resource Server, if the AS and RS share the
>> storage for clients' public keys. Things are a little difficult if the AS 
>> and RS
>> are separate. Probably the Access Token or its introspection result have to
>> include the public key (instead of its thumbprint as described in section 7).
>> 
>> If the client registers multiple keys with the AS, it needs to specify which 
>> key
>> it uses to sign the DPoP Proof. However, there is still no absolute need to 
>> send
>> the whole key in DPoP Proof. Instead, the client could use "kid" header
>> parameter to specify the key.
>> 
>> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1], but 
>> I'm
>> not sure what happened to the discussion. There was also a comment on the 
>> latest
>> draft about the "jwk" header parameter [*2]. I agree with using the same DPoP
>> Proof structure for requests to AS and RS, but I think there are some cases
>> where we can omit "jwk" in BOTH requests. Making "jwk" 

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Dick Hardt]

+1

KISS
ᐧ

On Tue, Sep 8, 2020 at 3:55 PM John Bradley  wrote:

> +1
> On 9/8/2020 7:45 PM, Brian Campbell wrote:
>
> Indeed there are cases, as you point out, where the key might be knowable
> to the server via some other means, which makes the "jwk" header in the
> DPoP proof not strictly necessary. And while omitting the key in such cases
> would reduce the size of some messages (the DPoP proof anyway), such
> optionality would add complexity to implementations and deployments (and
> that kind of complexity can and often does degrade interoperability and
> even security). How, for example, would a client know if the access token
> includes the public key and thus whether or not to include the key with the
> proof? Sure the access token could always include the key (rather than
> thumbprint) but then there's the question of how to get the key to the AS.
> As well as the stated desire to utilize the same DPoP Proof structure for
> requests to both the AS and RS. There will be some clients that have public
> key(s) registered and some that won't (maybe a lot that won't as a driving
> use case for many for this is key binding access and refresh tokens for
> public clients). The protocol defined by the draft needs to account for
> both.
>
> Ultimately there are a number of different ways the necessary data could
> flow through the various protocol elements. And there are some tradeoffs
> with different approaches and/or trying to accommodate variations under one
> approach. The approach the draft has taken thus far is to prioritize
> consistency and simplicity as much as is possible. And that ethos has led
> to how it's currently defined, which is to always include the key in the
> proof and bind to a hash of the key in the access token.
>
>
> On Tue, Sep 8, 2020 at 3:29 AM  wrote:
>
>> Hi all,
>>
>> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
>> REQUIRED. However, there are some cases where "jwk" is not necessary in
>> theory.
>>
>> For example, consider a case where the client is registered with the
>> Authorization Server, and its one and only public key is also registered
>> with
>> the AS. In that case, when the AS receives a request on Token endpoint,
>> it can
>> just use the public key registered for the client to verify the DPoP
>> Proof.
>> There is no need to send the public key in DPoP Proof.
>>
>> The same goes for requests to the Resource Server, if the AS and RS share
>> the
>> storage for clients' public keys. Things are a little difficult if the AS
>> and RS
>> are separate. Probably the Access Token or its introspection result have
>> to
>> include the public key (instead of its thumbprint as described in section
>> 7).
>>
>> If the client registers multiple keys with the AS, it needs to specify
>> which key
>> it uses to sign the DPoP Proof. However, there is still no absolute need
>> to send
>> the whole key in DPoP Proof. Instead, the client could use "kid" header
>> parameter to specify the key.
>>
>> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1],
>> but I'm
>> not sure what happened to the discussion. There was also a comment on the
>> latest
>> draft about the "jwk" header parameter [*2]. I agree with using the same
>> DPoP
>> Proof structure for requests to AS and RS, but I think there are some
>> cases
>> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would
>> allow
>> those cases to reduce some messaging overhead.
>>
>> I'd like to hear your opinions about it.
>>
>>
>> [*1]:
>> https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
>> [*2]:
>> https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/
>>
>>
>> Best regards,
>> Toshio Ito
>>
>> -
>> Toshio Ito
>> Research and Development Center
>> Toshiba Corporation
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *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 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] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[John Bradley]

+1

On 9/8/2020 7:45 PM, Brian Campbell wrote:
> Indeed there are cases, as you point out, where the key might be
> knowable to the server via some other means, which makes the "jwk"
> header in the DPoP proof not strictly necessary. And while omitting
> the key in such cases would reduce the size of some messages (the DPoP
> proof anyway), such optionality would add complexity to
> implementations and deployments (and that kind of complexity can and
> often does degrade interoperability and even security). How, for
> example, would a client know if the access token includes the public
> key and thus whether or not to include the key with the proof? Sure
> the access token could always include the key (rather than thumbprint)
> but then there's the question of how to get the key to the AS. As well
> as the stated desire to utilize the same DPoP Proof structure for
> requests to both the AS and RS. There will be some clients that have
> public key(s) registered and some that won't (maybe a lot that won't
> as a driving use case for many for this is key binding access and
> refresh tokens for public clients). The protocol defined by the draft
> needs to account for both.
>
> Ultimately there are a number of different ways the necessary data
> could flow through the various protocol elements. And there are some
> tradeoffs with different approaches and/or trying to accommodate
> variations under one approach. The approach the draft has taken thus
> far is to prioritize consistency and simplicity as much as is
> possible. And that ethos has led to how it's currently defined, which
> is to always include the key in the proof and bind to a hash of the
> key in the access token.
>
>
> On Tue, Sep 8, 2020 at 3:29 AM  > wrote:
>
> Hi all,
>
> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header
> parameter is
> REQUIRED. However, there are some cases where "jwk" is not
> necessary in theory.
>
> For example, consider a case where the client is registered with the
> Authorization Server, and its one and only public key is also
> registered with
> the AS. In that case, when the AS receives a request on Token
> endpoint, it can
> just use the public key registered for the client to verify the
> DPoP Proof.
> There is no need to send the public key in DPoP Proof.
>
> The same goes for requests to the Resource Server, if the AS and
> RS share the
> storage for clients' public keys. Things are a little difficult if
> the AS and RS
> are separate. Probably the Access Token or its introspection
> result have to
> include the public key (instead of its thumbprint as described in
> section 7).
>
> If the client registers multiple keys with the AS, it needs to
> specify which key
> it uses to sign the DPoP Proof. However, there is still no
> absolute need to send
> the whole key in DPoP Proof. Instead, the client could use "kid"
> header
> parameter to specify the key.
>
> Daniel Fett once mentioned the above case in the GitHub issue #26
> [*1], but I'm
> not sure what happened to the discussion. There was also a comment
> on the latest
> draft about the "jwk" header parameter [*2]. I agree with using
> the same DPoP
> Proof structure for requests to AS and RS, but I think there are
> some cases
> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL
> would allow
> those cases to reduce some messaging overhead.
>
> I'd like to hear your opinions about it.
>
>
> [*1]:
> https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
> [*2]:
> https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/
>
>
> Best regards,
> Toshio Ito
>
> -
> Toshio Ito
> Research and Development Center
> Toshiba Corporation
>
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> /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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Brian Campbell]

Indeed there are cases, as you point out, where the key might be knowable
to the server via some other means, which makes the "jwk" header in the
DPoP proof not strictly necessary. And while omitting the key in such cases
would reduce the size of some messages (the DPoP proof anyway), such
optionality would add complexity to implementations and deployments (and
that kind of complexity can and often does degrade interoperability and
even security). How, for example, would a client know if the access token
includes the public key and thus whether or not to include the key with the
proof? Sure the access token could always include the key (rather than
thumbprint) but then there's the question of how to get the key to the AS.
As well as the stated desire to utilize the same DPoP Proof structure for
requests to both the AS and RS. There will be some clients that have public
key(s) registered and some that won't (maybe a lot that won't as a driving
use case for many for this is key binding access and refresh tokens for
public clients). The protocol defined by the draft needs to account for
both.

Ultimately there are a number of different ways the necessary data could
flow through the various protocol elements. And there are some tradeoffs
with different approaches and/or trying to accommodate variations under one
approach. The approach the draft has taken thus far is to prioritize
consistency and simplicity as much as is possible. And that ethos has led
to how it's currently defined, which is to always include the key in the
proof and bind to a hash of the key in the access token.


On Tue, Sep 8, 2020 at 3:29 AM  wrote:

> Hi all,
>
> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
> REQUIRED. However, there are some cases where "jwk" is not necessary in
> theory.
>
> For example, consider a case where the client is registered with the
> Authorization Server, and its one and only public key is also registered
> with
> the AS. In that case, when the AS receives a request on Token endpoint, it
> can
> just use the public key registered for the client to verify the DPoP Proof.
> There is no need to send the public key in DPoP Proof.
>
> The same goes for requests to the Resource Server, if the AS and RS share
> the
> storage for clients' public keys. Things are a little difficult if the AS
> and RS
> are separate. Probably the Access Token or its introspection result have to
> include the public key (instead of its thumbprint as described in section
> 7).
>
> If the client registers multiple keys with the AS, it needs to specify
> which key
> it uses to sign the DPoP Proof. However, there is still no absolute need
> to send
> the whole key in DPoP Proof. Instead, the client could use "kid" header
> parameter to specify the key.
>
> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1],
> but I'm
> not sure what happened to the discussion. There was also a comment on the
> latest
> draft about the "jwk" header parameter [*2]. I agree with using the same
> DPoP
> Proof structure for requests to AS and RS, but I think there are some cases
> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would allow
> those cases to reduce some messaging overhead.
>
> I'd like to hear your opinions about it.
>
>
> [*1]:
> https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
> [*2]:
> https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/
>
>
> Best regards,
> Toshio Ito
>
> -
> Toshio Ito
> Research and Development Center
> Toshiba Corporation
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Takahiko Kawasaki]

To enable each "instance" of a client application to use a key pair which
is dedicated to the instance, the public key needs to be included in the
DPoP proof. On the other hand, in the scenario you described, all instances
of the client application have to share one key pair. If client application
instances don't have to share one key pair, it's better.

Illustrated DPoP (OAuth Access Token Security Enhancement)
https://medium.com/@darutk/illustrated-dpop-oauth-access-token-security-enhancement-801680d761ff

Best Regards,
Takahiko Kawasaki

On Tue, Sep 8, 2020 at 6:29 PM  wrote:

> Hi all,
>
> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
> REQUIRED. However, there are some cases where "jwk" is not necessary in
> theory.
>
> For example, consider a case where the client is registered with the
> Authorization Server, and its one and only public key is also registered
> with
> the AS. In that case, when the AS receives a request on Token endpoint, it
> can
> just use the public key registered for the client to verify the DPoP Proof.
> There is no need to send the public key in DPoP Proof.
>
> The same goes for requests to the Resource Server, if the AS and RS share
> the
> storage for clients' public keys. Things are a little difficult if the AS
> and RS
> are separate. Probably the Access Token or its introspection result have to
> include the public key (instead of its thumbprint as described in section
> 7).
>
> If the client registers multiple keys with the AS, it needs to specify
> which key
> it uses to sign the DPoP Proof. However, there is still no absolute need
> to send
> the whole key in DPoP Proof. Instead, the client could use "kid" header
> parameter to specify the key.
>
> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1],
> but I'm
> not sure what happened to the discussion. There was also a comment on the
> latest
> draft about the "jwk" header parameter [*2]. I agree with using the same
> DPoP
> Proof structure for requests to AS and RS, but I think there are some cases
> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would allow
> those cases to reduce some messaging overhead.
>
> I'd like to hear your opinions about it.
>
>
> [*1]:
> https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
> [*2]:
> https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/
>
>
> Best regards,
> Toshio Ito
>
> -
> Toshio Ito
> Research and Development Center
> Toshiba Corporation
>
> ___
> 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