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
