Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-04.txt

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 <bcampbell@pingidentity.com> 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 <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> 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=40microsoft.com@dmarc.ietf.org <mailto:40microsoft.com@dmarc.ietf.org>> 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 <oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>> On Behalf Of Brian Campbell
>> Sent: Monday, October 4, 2021 3:11 PM
>> To: oauth <oauth@ietf.org <mailto:oauth@ietf.org>>
>> 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: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>> 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
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> 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
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> 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.