Well, you could do all of these things, but additional DH computations have a cost and so they need to be justified. Adding in a server static key provides authentication of the server, which could provide defence in depth against a MITM attack (as you say), but such a MITM attack assumes HTTPS ha
One potential mitigation is multiple DH, where the server has a static key
*and* ephemeral key. Then the shared secret for HMAC becomes:
KDF(DH(client_ephemeral, server_static) || DH(client_ephemeral,
server_ephemeral))
For the cost of an additional client <-> server interaction (to share t
Right. A key difference between what I proposed and what Zack is proposing, as I understand it, is that in my proposal the server (RS) challenges the client with a fresh ephemeral public key (periodically or once per session, according to server policy). In Zack’s proposal the server has a static p
Thanks, this is really useful context! There are other places in OAuth where I
think more DH could be useful (e.g. removing a network hop from PKCE by
replacing the code challenge with an ephemeral public key, and having the
authorization server derive a key and then directly return an access to
Hi Zack,
For whatever it's worth, HMAC PoP has been discussed in the past (in a few
different incarnations). Neil Madden put forth the idea of a somewhat
similar sounding Diffie-Hellman style approach
https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s/,
which I sort of propose
Hi OAuth list,
Hopefully this is the right place for this message. I wanted to surface an idea
for an alternative DPoP approach to the current one based on digital
signatures. I'm looking for feedback to determine whether it's worth
investigating further or writing up a proper RFC. Is there any
