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

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> 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 <oauth-bounces@ietf.org> On Behalf Of Brian Campbell
> Sent: Monday, October 4, 2021 3:11 PM
> To: oauth <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>
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe 
<https://preferences.forgerock.com/>