Subject: [OAUTH-WG] DPoP followup III: client auth

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Dec 2020 15:29:00 -0700

There were a few items discussed somewhat during the recent interim
<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth>
that I committed to bringing back to the list. The slide below (also
available with a few extra spelling errors as slide #19 from the interim
presentation
<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>)
is the last of them.

To summarize, I'm wondering if there's WG interest in working to formalize
a client-to-AS authentication mechanism based on DPoP. I think it
potentially would be problematic to put into the current document (for a
number of reasons) so am preemptively ruling out that option. Thus,
basically, I'm asking the WG if there is some/much interest in the idea? In
which case I'll find some time (at some point) to write up an I-D for it
and bring that back to the group for consideration. Or if I should, as the
slide says, "shut up and never speak of this again"?

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

---

From: Filip Skokan <[email-masked]>
Date: Thu, 3 Dec 2020 10:46:23 +0100

🤫, better not open up the possibility of thinking of DPoP Proof keys as
pre-registered (i.e. not "ephemeral").

Best,
*Filip*

On Wed, 2 Dec 2020 at 23:30, Brian Campbell <bcampbell=
[email-masked]> wrote:

> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Neil Madden <[email-masked]>
Date: Thu, 3 Dec 2020 11:03:14 +0000

I like the last option :-)

> On 2 Dec 2020, at 22:29, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> There were a few items discussed somewhat during the recent interim <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth> that I committed to bringing back to the list. The slide below (also available with a few extra spelling errors as slide #19 from the interim presentation <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>) is the last of them.
> 
> To summarize, I'm wondering if there's WG interest in working to formalize a client-to-AS authentication mechanism based on DPoP. I think it potentially would be problematic to put into the current document (for a number of reasons) so am preemptively ruling out that option. Thus, basically, I'm asking the WG if there is some/much interest in the idea? In which case I'll find some time (at some point) to write up an I-D for it and bring that back to the group for consideration. Or if I should, as the slide says, "shut up and never speak of this again"?
> 
> 
> 
> 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
> [email-masked]

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

---

From: <[email-masked]>
Date: Fri, 4 Dec 2020 01:26:10 +0000

Hi Brian, everyone

I'm interested in a client authentication method based on DPoP. It'd be a good
option for application-layer client authentication with asymmetric keys.

However, I don't think the DPoP draft should include DPoP as a client
authentication method. It should be a different document. In addition, I'm not
sure we can (or should) use exactly the same DPoP Proof JWT structure for client
authentication.

Toshio Ito

From: OAuth <[email-masked]> On Behalf Of Brian Campbell
Sent: Thursday, December 3, 2020 7:29 AM
To: oauth <[email-masked]>
Subject: [OAUTH-WG] DPoP followup III: client auth

There were a few items discussed somewhat during the recent interim<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth> that I committed to bringing back to the list. The slide below (also available with a few extra spelling errors as slide #19 from the interim presentation<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>) is the last of them.

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.

---

From: Michael A Peck <[email-masked]>
Date: Fri, 4 Dec 2020 15:21:23 +0000

Hi Brian,

I think I lean towards  “Shut up and never speak of this again”, but could you clarify some things?

I missed the interim meeting discussion on this slide – it looks like DPoP for client authentication would have very similar properties as private_key_jwt, but using DPoP instead? i.e. both use a private key to sign a JWT that authenticates the client.

Could you expand a bit on the advantage of using DPoP for both client authentication and sender-constraining the token vs. using private_key_jwt (for client authentication) + DPoP (for sender-constraining the token)?

Adding to Filip’s comment, is there just one DPoP proof sent in the token request to cover both client authentication and sender-constraining the token, meaning the same keypair would be used for both DPoP usages?  That would go against DPoP’s key rotation guidance, but maybe would be okay if freshness guarantees of the DPoP proof get added?

Thanks,
Mike

From: OAuth <[email-masked]> on behalf of Filip Skokan <[email-masked]>
Date: Thursday, December 3, 2020 at 4:49 AM
To: Brian Campbell <bcampbell=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [EXT] Re: [OAUTH-WG] DPoP followup III: client auth

🤫, better not open up the possibility of thinking of DPoP Proof keys as pre-registered (i.e. not "ephemeral").

Best,
Filip

On Wed, 2 Dec 2020 at 23:30, Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>> wrote:
There were a few items discussed somewhat during the recent interim<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth> that I committed to bringing back to the list. The slide below (also available with a few extra spelling errors as slide #19 from the interim presentation<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>) is the last of them.

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Denis <[email-masked]>
Date: Fri, 4 Dec 2020 18:38:28 +0100

Hi Michael,

> I missed the interim meeting discussion on this slide – it looks like 
> DPoP for client authentication would have very similar properties as 
> private_key_jwt, but using DPoP instead? i.e. both use a private key 
> to sign a JWT that authenticates the client.
>
> Could you expand a bit on the advantage of using DPoP for both client 
> authentication and sender-constraining the token vs. using 
> private_key_jwt (for client authentication) + DPoP (for 
> sender-constraining the token)?
>
> Adding to Filip’s comment, is there just one DPoP proof sent in the 
> token request to cover both client authentication and 
> sender-constraining the token, meaning the same keypair would be used 
> for both DPoP usages?  That would go against DPoP’s key rotation 
> guidance, but maybe would be okay if freshness guarantees of the DPoP 
> proof get added?
>
One or more client-AS authentication methods using asymmetric 
cryptography might be developed in a separate draft.
However this does not mean that they should be based on the DPoP 
protocol. FIDO is one example of such a protocol, but its public key 
registration protocol
has a weakness: after registration, the server has no proof that the 
client indeed possesses the private key, unless/until an authentication 
exchange is performed afterwards.

Different keys should be used for DPoP and client-AS authentication. See 
an email related to privacy considerations about which key pairs may be 
used for DPoP :
https://mailarchive.ietf.org/arch/browse/oauth/?q=Proposed%20text%20for%20a%20Privacy%20considerations%20section%20in%20draft-ietf-oauth-dpop-02

Denis

> Thanks,
>
> Mike
>
> *From: *OAuth <[email-masked]> on behalf of Filip Skokan 
> <[email-masked]>
> *Date: *Thursday, December 3, 2020 at 4:49 AM
> *To: *Brian Campbell <bcampbell=[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *[EXT] Re: [OAUTH-WG] DPoP followup III: client auth
>
> 🤫, better not open up the possibility of thinking of DPoP Proof keys 
> as pre-registered (i.e. not "ephemeral").
>
> Best,
> *Filip*
>
> On Wed, 2 Dec 2020 at 23:30, Brian Campbell 
> <bcampbell=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     that I committed to bringing back to the list. The slide below
>     (also available with a few extra spelling errors as slide #19 from
>     the interim presentation
>     To summarize, I'm wondering if there's WG interest in working to
>     formalize a client-to-AS authentication mechanism based on DPoP. I
>     think it potentially would be problematic to put into the current
>     document (for a number of reasons) so am preemptively ruling out
>     that option. Thus, basically, I'm asking the WG if there is
>     some/much interest in the idea? In which case I'll find some time
>     (at some point) to write up an I-D for it and bring that back to
>     the group for consideration. Or if I should, as the slide says,
>     "shut up and never speak of this again"?
>
>
>     */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
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Dec 2020 11:58:05 -0700

> I think I lean towards  “Shut up and never speak of this again”, but could

That seems to be where rough consensus is heading. So the clarifications
are likely moot. But I'll try anyway.

>
>
> I missed the interim meeting discussion on this slide – it looks like DPoP
> for client authentication would have very similar properties as
> private_key_jwt, but using DPoP instead? i.e. both use a private key to
> sign a JWT that authenticates the client.
>

Time was running out in the meeting at the same time I somehow lost the
ability to advance slides.  So there wasn't any real discussion on this
one. But yes they would have very similar properties AFAICT.

> authentication and sender-constraining the token vs. using private_key_jwt
> (for client authentication) + DPoP (for sender-constraining the token)?
>

The only advantage would be avoiding sending two different JWTs in a one
request that are doing very similar things.  DPoP + private_key_jwt seemed
awkward in that respect when I thought about it. That was really my only
motivation for bringing it up.

>
>
> Adding to Filip’s comment, is there just one DPoP proof sent in the token
> request to cover both client authentication and sender-constraining the
> token, meaning the same keypair would be used for both DPoP usages?
>

That was the idea, yes.

> That would go against DPoP’s key rotation guidance, but maybe would be
> okay if freshness guarantees of the DPoP proof get added?
>

Yes kinda but the kind of client's that could use DPoP for client auth are
likely the kind that could rotate those keys via JWKS_URI and also be less
prone to the vectors (like XSS) which most benefit from rotation. Improved
(guarantee seems too strong a word) freshness probably makes it more okay
too.

>
>
> Thanks,
>
> Mike
>
>
>
>
>
> *From: *OAuth <[email-masked]> on behalf of Filip Skokan <
> [email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Dec 2020 12:01:59 -0700

On Thu, Dec 3, 2020 at 6:26 PM <[email-masked]> wrote:

> authentication method. It should be a different document.
>

Aggee. It'll go in a different document, if it happens at all.

> In addition, I'm not

If not, then RFC7523 private_key_jwt client auth is already defined and
available for application-layer client authentication with asymmetric keys.

>
>
>
>
> Toshio Ito
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Brian Campbell
> *Sent:* Thursday, December 3, 2020 7:29 AM
> *To:* oauth <[email-masked]>
> *Subject:* [OAUTH-WG] DPoP followup III: client auth
>
>
>
> your computer. Thank you.*
>