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

From: Mike Jones <[email-masked]>
Date: Wed, 6 Oct 2021 16:37:30 +0000

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-masked]> On Behalf Of Brian Campbell
Sent: Monday, October 4, 2021 3:11 PM
To: oauth <[email-masked]>
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-masked]<mailto:[email-masked]>>
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.

---

From: Neil Madden <[email-masked]>
Date: Wed, 6 Oct 2021 20:53:56 +0100

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-masked]> wrote:
> 
> 
> From: <[email-masked]>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

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