Yeah, I think you're right. I was only thinking about shared caches. I'll look to add something to sec 8.1. But, being nowhere near expert on HTTP coaching myself, I'm reluctant to add normative requirements. So the text will likely be more of a brief note/reminder than a normative MUST.
The discussions at OSW about nonce handling were useful but didn't come to any conclusions. If you have any thoughts or suggestions there, they'd be welcome. I'm hopeful we can find some guidance that is simple and makes implementation simple (like definitely not synchronizing nonces across instances of distributed client software) but that's proving a bit elusive thus far. On Mon, Nov 29, 2021 at 12:10 PM Neil Madden <[email protected]> wrote: > I’m by no means a HTTP caching expert (*), but > 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/ 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]> > 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 <Michael.Jones= >> [email protected]> wrote: >> >> >> >> FYI, I wrote about the nonce support at https://self-issued.info/?p=2194 >> and https://twitter.com/selfissued/status/1445789505902899206. >> >> >> >> -- Mike >> >> >> >> *From:* OAuth <[email protected]> *On Behalf Of * Brian Campbell >> *Sent:* Monday, October 4, 2021 3:11 PM >> *To:* oauth <[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]> >> 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 >> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ >> Html: >> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.html >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop >> Diff: >> 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] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe >> <https://preferences.forgerock.com/> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> 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.* > > > -- _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
