Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP

Brian Campbell <bcampbell@pingidentity.com> Wed, 02 December 2020 15:18 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 86E7F3A146B for <oauth@ietfa.amsl.com>; Wed, 2 Dec 2020 07:18:21 -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 D0q4sCy4erC7 for <oauth@ietfa.amsl.com>; Wed, 2 Dec 2020 07:18:18 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 23A443A14DD for <oauth@ietf.org>; Wed, 2 Dec 2020 07:18:11 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id q13so5291953lfr.10 for <oauth@ietf.org>; Wed, 02 Dec 2020 07:18:10 -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=2IseNF7EscnSiiJ7s6v+DZLvsEZOCYfZINp2302lNvI=; b=S0tUvrm6K3JtaJRd0iS2D+XZeGlEvGHLMePMbLaj0w0uE+8T2NNPZ/xQa1TVgl//+Z +L+KILvknt+AeDuBdDYgnjAz0uolPXbaOQDuft6qZsd/+UhoVNw+gndMweta01jVarO1 k1Wg/cugzinUfGbVcy/3CBZ1MTXyBG+OMDe+ihALJTUUv6xfqs4viMRNxp3p5Nzz7lEh +pBSH/bU8YyXMJXYcAoB3X++WQLrR4ZTVaqOtImvqcarb0fM+3JYlpe6KSLmzk4fbrJ8 Kr5Q02IwKdpRjv9sdZENUu4jO9TGquxaK0PjQ3t1FFYsDoPFOxeRxPdX+5U4sTvBCVfO YpWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2IseNF7EscnSiiJ7s6v+DZLvsEZOCYfZINp2302lNvI=; b=jx/f111twmfs1sq6InhNSJlLdxy7OFsKN+XriuiU6QTpWgPJHkpifZXS8T8KmngZSk uLehOTSsSQrK9T/LQi0/hzoQ/uFy1S4FeppZMD0TpgmU5Uf6xnusTSDUKRO9aRzzmnHo VP0MIJx+ftuuiHdKIqUbIlNUvedP30pRadYPmW2UNJ/G/y4yCkNmJdLhSmTI8Y4++tMb mES2v9j89cqaz25mxWxeKg3d16KQR/K4BxuZZ2F1ozuNhyehaGyq1JcWWkDwaA244GeV rzbFDBVk+9CKmSsWBgu07oVWkcvguXyRcDWNCPYLzo62HwTAE9GATbwp0khIBkA0wTe7 D/8A==
X-Gm-Message-State: AOAM533hjEEgA0TvFUav0Uzczm+iXYnaCCTUpkBl+7zXYIoSEh+mRiMP bOma9Y58vn+QDbHLpiDEHsyp22Y9gVeHhejQp/wN01AdRupHAiOzghnn5qq1KTlcsJS6Q7vZ1bS LbPjk4EtbWEd8FQ==
X-Google-Smtp-Source: ABdhPJyW/MiRbNwF11SVqIi+3Wr5ffKcu0L0la88fbB2ocC8OtPJ3q4u8LzyuFdGnbXYq3TWddh57XyZS+u/y0+vY9k=
X-Received: by 2002:a05:6512:3218:: with SMTP id d24mr1418831lfe.358.1606922289036; Wed, 02 Dec 2020 07:18:09 -0800 (PST)
MIME-Version: 1.0
References: <CADNypP-ef3z6WJ1DDOBhmh0CN4kRK_VACkzFaCLVxA3zCoEx0A@mail.gmail.com> <1b584adf-14f9-ba2e-657d-f22b57d87675@free.fr> <CA+k3eCQ+QKWfW8RsutYk94LmeHR+NWwHmxWJRnXLkHkRHEER-w@mail.gmail.com> <4cb35c85-e13a-aabe-1e74-d6eb244189cf@free.fr> <49cbbea5-df0e-f864-cf8b-ec9c3768bc18@danielfett.de> <ff65e3e5-a162-cea6-44b4-fc2ca905a9bb@free.fr>
In-Reply-To: <ff65e3e5-a162-cea6-44b4-fc2ca905a9bb@free.fr>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 2 Dec 2020 08:17:41 -0700
Message-ID: <CA+k3eCTpgnz9EcE09=y=Siggd1DrwQERnCThWL2GOSH2F9k07g@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000385d0c05b57cc077"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/eb4SS8dp6T-OGU4XekVx4t3Nqeg>
Subject: Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP
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: Wed, 02 Dec 2020 15:18:22 -0000

The conversation at
https://github.com/danielfett/draft-dpop/pull/51#discussion_r332377311 has
a bit more of the rational behind the choice of 96 bit minimum.

On Wed, Dec 2, 2020 at 7:07 AM Denis <denis.ietf@free.fr> wrote:

> Hi Daniel,
>
> All your arguments make sense. I agree.
>
> A minor point however. The size of the jti" is currently mandated to 96
> bits minimum. This is unnecessarily long for a time window of a few minutes.
> The jti" does not need to be a unique identifier valid for ever. It can
> simply be an identifier used during the time window which complements the
> "iat" claim.
>
> Using both the "iat" claim and a 32 bits pseudo-random number will be
> quite sufficient.  It is also has the advantage of using less memory and
> it is easier to flush the entries looking at the 32 first bits only.
>
> Denis
>
> So what you are proposing is that the time window in which an RS accepts
> the DPoP proof is defined by the expiration time of the access token?
>
> DPoP proofs are intended to be generally be short-lived and fresh for each
> request in order to provide some level of replay protection. There is no
> point in making the time window as long as the (typically longer) time
> window in which an AT would be accepted. A DPoP proof that is valid for 12
> hours would not provide much replay protection.
>
> The time window is left unspecified because it is only meant to account
> for clock differences and network latency. Its precise value can depend on
> deployment considerations. It is not intended to give the client an option
> to re-use proofs, which is prevented together with the jti.
>
> Also this would introduce new, unwanted and potentially surprising
> dependencies between token lifetimes and the DPoP usage.
>
> And finally, as discussed before, not all access tokens are JWTs and we
> are not going to mandate JWT access tokens in this spec.
>
> -Daniel
>
>
> Am 01.12.20 um 09:54 schrieb Denis:
>
> Hi  Brian,
>
> Hi Denis,
>
> The choice to use "iat" vs. "exp" was made in the summer of last year. You
> can see some of the discussion from then in
> https://github.com/danielfett/draft-dpop/issues/38.
> I believe it pretty well has consensus at this point and thus unlikely to
> be changed.
>
> I fear that you misread my email or read it too fast. My point had nothing
> to do whether using *either *of "iat" *o**r* "exp" in the DPoP proof JWT
> sent by the client.
>
> The first sentence of my email was: "One comment on slide 5 about the *time
> window*". So the topic was all about how the RS SHALL handle the "jti"
> claim included
> in the DPoP proof JWT when using a time window.
>
> While I do believe there are reasonable arguments that can be made on both
> sides of using either of "iat" or "exp", it's difficult (and honestly time
> consuming and very frustrating) to try and have such discussions or even
> respond in a coherent way when fundamental aspects of the draft are
> misrepresented or misunderstood. For example, the DPoP proof JWT is created
> by the client not the AS so the advantages you put forward are
> nonsensical in the context of the actual workings of the draft.
>
> Section 8.1 addresses the topic of the *time window*, but this topic
> should not *only *be addressed in the "Security Considerations" section
> but in the main body of the document, since some checks MUST be done by
> the RS. "Security Considerations"are intended to provide
> explanations but are not intended to be normative.
>
> Section 8.1 states:
>
>    " If an adversary is able to get hold of a DPoP proof JWT, the
> adversary could replay that token at the same endpoint (the HTTP
>    endpoint and method are enforced via the respective claims in the
> JWTs).  To prevent this, servers MUST only accept DPoP proofs
>    for a limited time window after their "iat" time, preferably only for a
> relatively brief period.
>
>    Servers SHOULD store, in the context of the request URI, the "jti"
> value of each DPoP proof for the time window in which the respective
>    DPoP proof JWT would be accepted and decline HTTP requests to the same
> URI for which the "jti" value has been seen before.  In order
>    to guard against memory exhaustion attacks a server SHOULD reject DPoP
> proof JWTs with unnecessarily large "jti" values or store only
>    a hash thereof.
>
>    (...) ".
>
> The previous text makes the assumption that RSs MUST only accept DPoP
> proofs for a relatively brief period after their "iat" time included
> in the DPoP proof JWT. This assumption is rather restrictive. A client
> might get an access token and associate it with DPoP proof JWT that
> could be used during, e.g., 12 hours. A DPoP proof JWT/ access token JWT
> pair could thus be used by a client during, e.g., one day for
> several sessions with a RS.
>
> The *time window* is currently left at the discretion of each RS and is
> supposed to be short (without stating explicitly what "short" may mean)..
>
> It would be possible to mandate in the JWT the inclusion of the exp
> (Expiration Time) Claim. (I am *not* advocating the inclusion of the
> "exp"
> claim in the DPoP proof JWT).
>
> In this way, for a RS, the *time window *would be defined using the "iat"
> claim defined in the DPoP proof JWT and the "exp" claim defined in
> the JWT.
>
> Such a description should not be done in section 8, but in a section
> earlier in the main body of the document.
>
> This would have the following advantages:
>
>    - The RS would be able to better manage the "jti" claim values,
>    because it would be able to discard "jti" claim values as soon as they are
>    outside the time window as defined above.
>
>
>    - The client would know whether a DPoP proof JWT/ access token JWT
>    pair is still usable, in particular using the "expires_in" status code
>    returned in case of a successful response from the AS and is thus
>    unlikely to get a rejection of both of them because of an unknown time
>    window used by a RS.
>
> Denis
>
>
> On Mon, Nov 30, 2020 at 8:45 AM Denis <denis.ietf@free.fr> wrote:
>
>> One comment on slide 5 about the *time window*.
>>
>> At the bottom, on the left, it is written: "Only valid for a limited *time
>> window* relative to creation time".
>>
>> While the creation time is defined by "iat", the *time window* is
>> currently left at the discretion of each RS.
>>
>> It would be preferable to mandate the inclusion in the JWT of the exp
>> (Expiration Time) Claim.
>> In this way, the *time window *would be defined by the AS using both the
>> "iat" and the "exp" claims.
>>
>> This would have the following advantages:
>>
>>    - The client will know whether a token is still usable and is
>>    unlikely to get a rejection of the token
>>    because of an unknown time window defined by a RS.
>>
>>
>>    - The RS is able to manage better the "jti" claim values, because it
>>    will be able to discard "jti" claim values
>>    as soon as they are outside the time window defined by the AS in a
>>    JWT.
>>
>> Denis
>>
>> All,
>>
>> This is a reminder that we have an Interim meeting this Monday, Nov 30th
>> @ 12:00pm ET, to discuss the latest with the *DPoP *document:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
>>
>> You can find the details of the meeting and the slides here:
>> https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth
>>
>> Regards,
>>  Rifaat & Hannes
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> 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.*
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> -- https://danielfett.de
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> 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._