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

Brian Campbell <bcampbell@pingidentity.com> Fri, 03 December 2021 21:45 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDBE3A09F2 for <oauth@ietfa.amsl.com>; Fri, 3 Dec 2021 13:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h3QlPYIEUhf for <oauth@ietfa.amsl.com>; Fri, 3 Dec 2021 13:45:46 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE9E3A09EE for <oauth@ietf.org>; Fri, 3 Dec 2021 13:45:46 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id r26so9587455lfn.8 for <oauth@ietf.org>; Fri, 03 Dec 2021 13:45:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6lOHc3JuyKzfc/a29IW62/QkiZ6JrtdlRYswuhM/ZrM=; b=VWiujld6f2UgHOO7YEWkAb1lzoRl6QIETbesSkBTruwuVN9sWzu7hvbhfDF28g+Ko7 9wmIJfDB6CmGpzUndYs7upp3ARcZuvZwIXbaW2mFay4tW1/16KQPZ6//Ymww480XgRnC et6qCbJkcJKCEp5kB9fO7FlvkmeyTk8Beb14aHJR4fz8ixqfBLSCSFEHkqg+0/p8RPut 6hA6lxdZIE8eME1Ihgf9Yqr7yIUVSHKF5u6Vdrxywn8wbius9nnZe05CFcZ0wATcDb9g lhAWPwOuUX1H3ls/3dDFbTxEDIY5uqHvchOJlsRwvLW+91C1pUztOdL8KHkd+N0hVCo7 8qUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6lOHc3JuyKzfc/a29IW62/QkiZ6JrtdlRYswuhM/ZrM=; b=e200lAEwhEdkUsjJWFu6yKCn9woUZReb56fxZiraKO15Qg4N9ECdO1HOWx38M7ux0p EpzQJTwjq7ToVSQRg2h0JcN2GLkbh4mIjtQlgnZR5pUxZmI5uDrkRCpqnryUL4jwVRzC 2zU5PFQjfr+h0TxY60LwbWAE74slc9H1FYtpkXG1+6giDq1h2g/woyltpuYAr0pjehWM XeOEgQFsa6+hSqWpvzqoYJDEd7797fNLsK4e6QjpAcmILH+UOh7hgr1IEkQYtxVxN6GR KcU8LnTJiNlPLbCeNByFK0uqfy2aOOiCF8/uFCKExc77HV4m5c/yp8TZU83HGHkwsAXH 8N7Q==
X-Gm-Message-State: AOAM532tPEbV3XRG3nuwZCk6oPlBy4z6r829mBiFCfAC0XcUdZDI81QL 92LBHz1DdBlWgRD8Xpc+yVb/22HBcObQc7mf/8oc7keTCOdIkuXNPaXmAlHosFAE+oCJNXZsAKS 2Aib6tQhxF/eswQ8DTOTyjA==
X-Google-Smtp-Source: ABdhPJwrPVxYgbwqLM7XzIpdpJC+s3/d+zcDA+pWKbdJlI/3F9mR9uKZlvFd5s5tJRz6lF7mnlKnnq9nDT1f0A3t9ZQ=
X-Received: by 2002:a19:5e59:: with SMTP id z25mr20604543lfi.686.1638567943791; Fri, 03 Dec 2021 13:45:43 -0800 (PST)
MIME-Version: 1.0
References: <PH0PR00MB09970FB8EB1884B8BF5A090CF5B09@PH0PR00MB0997.namprd00.prod.outlook.com> <BB556582-2CEC-4A73-ABF3-BFB9EB12B0D0@forgerock.com> <CA+k3eCTqx_w2d6um+kOW1er9Xe6DhsboXqGxSWWZeKWERUMzfA@mail.gmail.com> <EC811423-50B1-439D-A25A-D5AAD89B6CD3@forgerock.com>
In-Reply-To: <EC811423-50B1-439D-A25A-D5AAD89B6CD3@forgerock.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 03 Dec 2021 14:45:17 -0700
Message-ID: <CA+k3eCRS1KY_UUN=pcRRfDN0RcpDa2ROr7fptiAMPQ7ABi6HYg@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003b18b005d244d405"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/DEmWIR1lY7q2AbaSXP6HguWlK5s>
Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Dec 2021 21:45:52 -0000

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 <neil.madden@forgerock.com>
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 <bcampbell@pingidentity.com>
> 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 <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> 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/>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> 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._