Hi Rohan,
> On 22 Mar 2022, at 15:24, Rohan Mahy <[email protected]> > wrote: > > Here are some comments on draft-ietf-oauth-dpop-06: > > 1) With such a significant attack possible as DPoP proof pre-generation, why > isn't using the server nonce a SHOULD? Preventing a significant attack and > making lifetime handling sane are two excellent reasons to use a server > nonce. If an implementation has a good reason to not use a server nonce, we > can give guidance about what additional steps the implementation needs to > take. I think this is a good question, and I’ve been wondering about it myself. The argument I see for not more strongly requiring nonces is that it pushes additional and non-trivial implementation complexity onto clients (and arguably also onto resource servers). There are situations where I am not sure a nonce adds much value - for example in the case of a confidential client, an attacker with access to pre-generate DPoP proofs can likely also pre-generate private_key_jwt client authentication assertions and likely also has access to any refresh token. I believe this would allow them to obtain access tokens bound to a DPoP key of their choosing, and a nonce then seems to provide no additional protection. (There are also cases where the nonce clearly does add a lot of value, particularly when considering public clients, and there may well be an argument for a ’should’ in those cases. Conversely I think there’s a potential argument for saying you should not use nonces in the confidential client situation I outlined, as it adds little other than complexity.) Thanks Joseph _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
