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 token that’s AES-GCM encrypted with that derived key, etc.). Curious to know why OAuth tends to steer away from it so often.
On Wed, Jan 4, 2023, at 16:19, Brian Campbell wrote: > 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
