I’m by no means a HTTP caching expert (*), but https://datatracker.ietf.org/doc/html/rfc7234#section-3 <https://datatracker.ietf.org/doc/html/rfc7234#section-3> says that the non-cacheability of responses to requests with Authorization headers only applies to shared caches. So could a user-agent itself cache the response and incorrectly return a stale DPoP-Nonce response on a subsequent request?
But I think you’re right that this only applies, at most, to section 8.1, as DPoP only allows the Authorization header for making requests to the RS (unlike RFC 6750). (*) I know a joke about HTTP caching, but I think you’ve already heard it. — Neil > On 29 Nov 2021, at 18:03, Brian Campbell <[email protected]> wrote: > > I'm preparing some slides for a DPoP session tomowwo at the OAuth Security > Workshop https://barcamps.eu/osw2021/ <https://barcamps.eu/osw2021/> so > looking back at some threads like this one trying to compile a list of issues > needing attention. The stateful handling of server-supplied nonces is one > such topic. I was about to add a topic for Cache-Control but, in > doing/thinking about it, I believe that all cases that would use a DPoP-Nonce > response header are already not cacheable - response to POST, 401 challenge, > response to a request containing an authorization header - so I don't think > anything is needed. But let me know if I'm missing something. > > On Wed, Oct 6, 2021 at 1:54 PM Neil Madden <[email protected] > <mailto:[email protected]>> wrote: > Overall I think thus is good, but I have a few comments/suggestions: > > I think the stateful handling of server-supplied nonces (ie the client reuses > the same nonce until the server sends a new one) perhaps needs to be > clarified with respect to clients making concurrent requests. Especially > clients using multiple access tokens and/or DPoP keys (eg for different > users). Is the nonce specific to a particular access token? > > And we also need to consider a client that is itself a cluster of servers - > does such a client need to synchronise nonces across instances? Does the > AS/RS need to? (I can imagine this getting quite complex with different > requests from different client machines hitting different AS/RS servers). > > I think probably any use of the DPoP-Nonce response header should also be > accompanied by Cache-Control: private (or no-store) and this should be a > MUST. I think we’ve also missed that the DPoP header on requests should also > have Cache-Control: no-store added, at least when not sending the access > token in an Authorization header. > > It seems slightly odd that the WWW-Authenticate challenge for RS > server-supplied nonces isn’t self-contained, but I don’t see anything that > says it should be so that is probably ok. (And I can see the consistency > argument for using the header). > > It does seem a shame to pay the cost of a challenge-response roundtrip and > not to do a key exchange to speed up subsequent requests, but never mind. > > — Neil > >> On 6 Oct 2021, at 17:37, Mike Jones >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> FYI, I wrote about the nonce support at https://self-issued.info/?p=2194 >> <https://self-issued.info/?p=2194> and >> https://twitter.com/selfissued/status/1445789505902899206 >> <https://twitter.com/selfissued/status/1445789505902899206>. >> >> >> >> -- Mike >> >> >> >> From: OAuth <[email protected] <mailto:[email protected]>> On >> Behalf Of Brian Campbell >> Sent: Monday, October 4, 2021 3:11 PM >> To: oauth <[email protected] <mailto:[email protected]>> >> Subject: [OAUTH-WG] Fwd: New Version Notification for >> draft-ietf-oauth-dpop-04.txt >> >> >> >> >> >> WG, >> >> >> >> The collective DPoP co-authors are pleased to announce that a new -04 >> revision of DPoP has been published. The doc history snippet is copied below >> for quick/easy reference. The main change here is the addition of an option >> for a server-provided nonce in the DPoP proof. >> >> >> -04 >> * Added the option for a server-provided nonce in the DPoP proof. >> * Registered the invalid_dpop_proof and use_dpop_nonce error codes. >> * Removed fictitious uses of realm from the examples, as they added >> no value. >> * State that if the introspection response has a token_type, it has >> to be DPoP. >> * Mention that RFC7235 allows multiple authentication schemes in >> WWW-Authenticate with a 401. >> * Editorial fixes. >> >> >> ---------- Forwarded message --------- >> From: <[email protected] <mailto:[email protected]>> >> Date: Mon, Oct 4, 2021 at 4:05 PM >> Subject: New Version Notification for draft-ietf-oauth-dpop-04.txt >> To: ... >> >> >> >> >> A new version of I-D, draft-ietf-oauth-dpop-04.txt >> has been successfully submitted by Brian Campbell and posted to the >> IETF repository. >> >> Name: draft-ietf-oauth-dpop >> Revision: 04 >> Title: OAuth 2.0 Demonstrating Proof-of-Possession at the >> Application Layer (DPoP) >> Document date: 2021-10-04 >> Group: oauth >> Pages: 37 >> URL: https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.txt >> <https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.txt> >> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ >> <https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/> >> Html: >> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.html >> <https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.html> >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop >> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop> >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-04 >> <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dpop-04> >> >> Abstract: >> This document describes a mechanism for sender-constraining OAuth 2.0 >> tokens via a proof-of-possession mechanism on the application level. >> This mechanism allows for the detection of replay attacks with access >> and refresh tokens. >> >> >> >> >> The IETF Secretariat >> >> >> >> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe > <https://preferences.forgerock.com/> > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
