Re: [OAUTH-WG] [EXT] Re: DPoP followup III: client auth

[Denis <[e-mail]>]

Hi Michael,

> 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?
>
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 <[e-mail]> on behalf of Filip Skokan 
> <[e-mail]>
> *Date: *Thursday, December 3, 2020 at 4:49 AM
> *To: *Brian Campbell <bcampbell=[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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=[e-mail] 
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth