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 the
public half of the server ephemeral key), you get these benefits:
* Harder for an attacker to pull off a simple MITM because the static server
key should be 'well known' (i.e. obtained by the client out of band of the
OAuth flow itself)
* Harder for an attacker in possession of the server static key to impersonate
clients to the server, because they would need the server ephemeral private key
(and I'm assuming/hoping that'd be stored elsewhere).
You could also replace the OAuth 2.0 'client secret' with a client static key,
and then you'd build the shared secret as:
KDF(DH(client_ephemeral, server_static) || DH(client_static,
server_ephemeral) || DH(client_ephemeral, server_ephemeral))
To me, this just starts to resemble existing protocols for secure messaging
with forward secrecy. How far is it worth taking this before we're building
OAuth 3.0/'mutual' OAuth? (I'm half joking and half serious)
On Thu, Jan 5, 2023, at 15:37, Neil Madden wrote:
>
> 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
> public key that is shared between all clients. This is more efficient but has
> some downsides:
>
> Firstly, the use of an ephemeral challenge ensures freshness, which prevents
> replay attacks. Part of the reason for my proposal was to avoid the need for
> timestamps, server-side blocklists, nonces, etc. If the RS key pair is static
> then you don’t get this nice property.
>
> Secondly, and more seriously, ECDH with a static key-pair is vulnerable to an
> attack known as key compromise impersonation (KCI). If the server’s private
> key is compromised, the attacker can not only impersonate the RS to any
> client, but can also impersonate any client when talking to the RS. So
> compromising the RS private key becomes an attractive target, requiring
> significant investment in countermeasures (HSMs etc).
>
> (This attack is not relevant for ECDH-ES normally because it is an attack
> against authentication and that encryption mode is unauthenticated anyway in
> its intended use).
>
> Cheers,
>
> Neil
>
> PS - I like K-PoP!
>
>> On 5 Jan 2023, at 00:20, Brian Campbell
>> <bcampbell=40pingidentity....@dmarc.ietf.org> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
