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 proposed as an option to the WG back when DPoP was being considered for adoption (slide 8 of https://datatracker.ietf.org/meeting/interim-2020-oauth-02/materials/slides-interim-2020-oauth-02-sessa-oauth-20-proof-of-possession-00.pdf). But there wasn't much interest at the time https://mailarchive.ietf.org/arch/msg/oauth/X-Fy2R3RqkP5lLDBuR820s3H-uE/ at least compared to working on DPoP w/ signatures. It's an interesting idea though and although it got sidelined I'd already started thinking about a name for it - KPoP, nominally for something like Key Agreement based Proof-of-Possession. Of course, Korean pop music already laid claim to the name K-pop so that might not be good for searchability. But I digress on names. Anyway, I don't know how useful this rambling is for you but it seemed worthwhile to mention some of the prior ideas and discussion on seemingly similar stuff.
On Wed, Jan 4, 2023 at 4:30 PM Zack Voase <zack=40meat...@dmarc.ietf.org> wrote: > 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 anything that > I'm overlooking about this scheme that would make it insecure, infeasible, > or undesirable? > > The idea is that rather than proof-of-possession being demonstrated by > asymmetric digital signatures attached to each request, it is demonstrated > by an HMAC, with the shared secret for the HMAC derived by ECDH-ES[0] > between the client and the server. For the purpose of this informal RFC, > I'll refer to the existing protocol as DPoP-DSA, and my proposed protocol > as DPoP-DH-HMAC. > > Similar to DPoP-DSA, the client would need its own asymmetric key pair, > and ideally this would be ephemeral (scoped to the life of a single > 'session', access token, or refresh token). The server would also need a > key pair, but static and well-known (probably published in a JWKS). > Optionally, the authorization server and resource server(s) could have > distinct keys from each other, and the client would derive the appropriate > HMAC secret for the server it's communicating with. > > The protocol would look very similar to DPoP-DSA, except that DPoP proofs > would be HS256-signed JWTs. I'm not entirely sure what the other JWT header > keys should look like, since the JSON Web Algorithms spec only allows > specification of ECDH-ES for agreeing on content encryption or wrapping > keys, not shared secrets for HMACs. Ideally JWS/JWT syntax could be > extended to allow a similar format as in RFC 7518 Appendix C ( > https://www.rfc-editor.org/rfc/rfc7518.html#appendix-C), but for this > kind of application. Furthermore, RFC 7518 recommends the use of Concat KDF > for final key derivation from the ECDH-ES agreed key, but Concat KDF is not > available in any common Web Crypto API implementations. HKDF, however, > is—maybe that should be used instead? > > Pros > ==== > > * HMAC-SHA256 computation is substantially cheaper than EC/RSA signing and > verifying. With good (and hopefully secure) caching, the ECDH-ES key > agreement algorithm only needs to be done once per access token on each of > the client and server. In most cases the one-time cost of secret derivation > can be amortized over a large number of HMAC verifications, but even for a > single usage, performance should be comparable between the two. > > * ECDSA is very vulnerable to issues with the entropy of the per-signature > nonce[1] (note that this does not refer to the DPoP nonce, rather the nonce > provided to the low-level ECDSA algorithm). A single reuse of a nonce > between two signatures is enough to completely determine the private key. > Even a small correlation between nonces can be attacked across enough > signatures. This creates some side-channel risks on clients, which might be > harder places to control such risk than OAuth servers. > > * Some side-channel and cryptanalytical attacks on signature algorithms > benefit from repeated observations of signature operations, whether through > timing, power use, or the numerical properties of the output (see [2] for > an example). In DPoP-DSA, a large number of observations is possible—one > for each request containing a proof. In DPoP-DH-HMAC, key derivation > happens exactly once per distinct (client key, server key) combination, > which may only be once per access/refresh token. This greatly constrains > the potential for key information to be leaked. Furthermore, this system > benefits from the security properties of SHA256: once the shared secret has > been derived, observing the timing/power usage of the per-request signing > operation, and/or the signatures themselves, can reveal absolutely nothing > about the keys. > > * Client keys should be ephemeral, scoped to the length of a single > refresh or access token. However, in the case that a client key is static, > or spans the life of the refresh token with many access tokens, some > additional data can be mixed into the key derivation function (whether > Concat KDF or HKDF) per access token, to reduce the impact of HMAC secret > exfiltration. > > * I'm not sure if it's immediately useful, but there's an aspect to this > scheme whereby only the sender and intended recipient (the server) can > verify a proof. There might exist some benefits there about > decoys/privacy/plausible deniability, but I haven't thought too much about > this. > > Cons > ==== > > * Servers would need to maintain a set of public, static keys, with > revocations and lifetimes and all the other complexities that go along with > long-term key management. > > * Servers must do constant-time validation of HMACs, otherwise proofs can > be brute-forced much more easily by observing timing (though it would be > quite hard not to notice this on the server). This is another reason to > keep track of nonces, whether server-provided or client-generated, and > reject requests with nonces that have been seen before. A lot of > implementations forget to add nonces from failed requests to their 'seen' > set, and this is a big oversight that can create replay/timing attacks. > > * ECDH implementations must check that provided public keys are valid > (see: invalid curve attacks[3]). This mainly applies to servers, and is > obviated by the fact that many major crypto libraries *do* validate > provided EC points. Ideally we could use Curve25519-based algorithms to > avoid some of these issues (including timing attacks, invalid curves/small > groups, etc.), but support for X25519/Ed25519 is very inconsistent in Web > Crypto and JOSE implementations. > > Thank you to whoever made it this far, and please don't hesitate to share > your thoughts/comments. > > -- Zack Voase > > [0]: https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6 > [1]: https://blog.trailofbits.com/2020/06/11/ecdsa-handle-with-care/ > [2]: https://d-nb.info/1205171657/34 > [3]: > https://blog.trailofbits.com/2018/08/01/bluetooth-invalid-curve-points/ > > _______________________________________________ > 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
