Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Philippe De Ryck <philippe@pragmaticwebsecurity.com> Mon, 20 April 2020 07:06 UTC

Return-Path: <philippe@pragmaticwebsecurity.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 F139C3A12D7 for <oauth@ietfa.amsl.com>; Mon, 20 Apr 2020 00:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.178
X-Spam-Level:
X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=WWKNxwiM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SVR3zncf
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 8fZqhbgD7xZD for <oauth@ietfa.amsl.com>; Mon, 20 Apr 2020 00:05:59 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E57D3A12DB for <oauth@ietf.org>; Mon, 20 Apr 2020 00:05:59 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 2E38E5A2; Mon, 20 Apr 2020 03:05:51 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 20 Apr 2020 03:05:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=Ca7ZBxXA3UeWq8MQMgTJJELitYV+RNliuopMF0opXBE=; b=WWKNxwiMyCfs ZVeiEE5ZJOVSkMPgGYfpKnhSc+tALasPInQVHCE0bNtLKckpOJoMd0+1I+VRZTd9 pRGoWfcJHh6Pl5rYtl5U95FuovIa98+phrs5/qYuOD6S2QEX3FSPC+ajtuLWUHi9 8cQHf0D/rZbCDY+pOdAglhGmA3jlYF6AzNR5Nd7PazFugTJ3oxZSOGYtx2/JSkUy pSeauWnY2m+8m/D2dQ4TL9URFfyQ1Q/Gv1cqEEQYWt5iC+Yj1na1LdI/zU4NJLYn be07s7CVx6jg0xcv2KlgQfQc/jiqAZwx79LUClJCtvfPa7Oh90uOEVc5TsitM9WY M7DMViSEKA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Ca7ZBx XA3UeWq8MQMgTJJELitYV+RNliuopMF0opXBE=; b=SVR3zncfAkbfsxtllDEVPT 68JepZ1EvsyBEPKjPs8JH6INYEmbo9+1DdFg6Vw5236NlOHUi5N+8Qfb7aycmVwE 7EJTM5IxcUeTHGa9b3Q3wmBHIwDUMZdhSaqF6Xy2Z1GI3KsXMSVvEJxqBsCom9FF /BpzcO5C7m4Nq5rUa91ZzMY2xM7drYquBSH9iOp1ARUwciQQ7Cs7bqC+KXuzmm/6 cKnGLBZ6DB6+4zu3vrhrWdpwegMczFxdR2EinNj93imGf4QRxQjIo59KiMxOJqQz sTbPBnSkArByTmBiwa8achfYxSynY8kOxr0ePqNW+c2IuJN8evKHmOqwFyiH9LUA ==
X-ME-Sender: <xms:zkmdXvjIZp4n-TRjlqEODYNqToqmtwYNVadqFgpCcTVJmzm9Yw5q5Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgedvgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpefrhhhilhhi phhpvgcuffgvucfthigtkhcuoehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvggssh gvtghurhhithihrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeel gedrvddvhedrhedrudeivdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvggsshgvtghurhhi thihrdgtohhm
X-ME-Proxy: <xmx:zkmdXodGYFHL0EylXxK7ZoxX1gwclD5zarQSgEJRdxqVxnALr4zryQ> <xmx:zkmdXt8WMB_ZQOE1BA7wLdWUnEa5U5KIhnZDB5TW6GeYGc8U2QFS0g> <xmx:zkmdXiYj4tjiwRoenfk6M1yyiF6jmy2NeRsMzhe7bQs7VTcQHfIEVw> <xmx:zkmdXnmTLNkN7DDcLwbFja5qCzZOWD4mF6hi_MzaLZ80GZyHfwHPuA>
Received: from philippes-imac.localdomain (94-225-5-162.access.telenet.be [94.225.5.162]) by mail.messagingengine.com (Postfix) with ESMTPA id B69833065BF7; Mon, 20 Apr 2020 03:05:49 -0400 (EDT)
From: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
Message-Id: <452135A8-1B26-4815-9797-1D175431ADE6@pragmaticwebsecurity.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6BE79931-791A-470C-86ED-99F72534470D"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Mon, 20 Apr 2020 09:05:48 +0200
In-Reply-To: <CAO7Ng+tJVsO4GZZNmNx2-nirWsjQcZxu0T9g4w_95vkPANSSmQ@mail.gmail.com>
Cc: David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>, Vladimir Dzhuvinov <vladimir@connect2id.com>, Vittorio Bertocci <vittorio=40auth0.com@dmarc.ietf.org>, oauth@ietf.org
To: Dominick Baier <dbaier@leastprivilege.com>
References: <CAGL6epKuHTqLrZEjm0goKV+3jaPfTkN_JSLc0jfQyPqNzeP3aA@mail.gmail.com> <CAO7Ng+ucc5AQfxgA6FYMerhq5gW_d+AYo07x4hB2H7b798JnKg@mail.gmail.com> <d9b766d0-75dc-926b-8c8c-951f1d5aface@connect2id.com> <7C1FB185-3AB4-4DF1-897C-BE33B8D59304@alkaline-solutions.com> <CAO7Ng+tJVsO4GZZNmNx2-nirWsjQcZxu0T9g4w_95vkPANSSmQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6GMGrkBSY7_AVPJlZSkRAXcHgBI>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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: Mon, 20 Apr 2020 07:06:13 -0000

In theory, you can issue a token that only becomes valid in the future. That would have a different iat and nbf timestamp. I have not seen this in practice though. 

Given that RFC 7519 lists “iat” as informative, I would not change that behavior in a specific use case if there is no significant need to do so.

Philippe

> On 20 Apr 2020, at 08:50, Dominick Baier <dbaier@leastprivilege.com> wrote:
> 
> Just a quick data point - 
> 
> The Microsoft .NET JWT implementation checks for exp and nbf. Not iat.
> 
> I guess my real question is - what’s the difference between the two practically speaking - and shouldn’t be the more common (aka supported by most libraries) be used?
> 
> ———
> Dominick Baier
> 
> On 20. April 2020 at 06:59:47, David Waite (david=40alkaline-solutions.com@dmarc.ietf.org <mailto:david=40alkaline-solutions.com@dmarc.ietf.org>) wrote:
> 
>> There are a number of ambiguities and statements around using JWTs in various contexts:
>> 
>> 1. Some implementations interpret “iat" to also have the meaning of “nbf” in the absence of “nbf”, although this is AFAIK not prescribed by any spec
>> 2. The DPoP draft’s client-generated tokens have the resource servers use their own nbf/exp heuristics around “iat”, since the tokens are meant for immediate one time use by a party that may not have clock synchronization.
>> 3. There are recommendations in the JWT profile for OAuth that the AS may reject tokens based on an “iat” too far in the past or “exp” too far in the future, but not that “nbf” was too far in the past or that the interval between nbf and exp was too large.
>> 
>> The JWT spec also allows implementers to provide some leeway for clock skew. Presumably this meant validators and not JWT creators, although there is history of messages setting similar values to account for clock skew (e.g. SAML IDPs setting notBefore to one minute before issuance and notOnOrAfter 5 minutes after issuance). 
>> 
>> -DW
>> 
>>> On Apr 19, 2020, at 2:50 AM, Vladimir Dzhuvinov <vladimir@connect2id.com <mailto:vladimir@connect2id.com>> wrote:
>>> 
>>> On 16/04/2020 10:10, Dominick Baier wrote:
>>>> iat vs nbf
>>>> What’s the rationale for using iat instead of nbf. Aren’t most JWT libraries (including e.g. the ..NET one) looking for nbf by default?
>>> Developers often tend to intuitively pick up "iat" over "nbf" because it sounds more meaningful (my private observation). So given the empirical approach of Vittorio to the spec, I suspect that's how "iat" got here.
>>> 
>>> If we bother to carefully look at the JWT spec we'll see that "iat" is meant to be "informational" whereas it's "nbf" that is intended to serve (together with "exp") in determining the actual validity window of the JWT.
>>> 
>>> https://tools.ietf.org/html/rfc7519#section-4.1.5 <https://tools.ietf.org/html/rfc7519#section-4.1.5>
>>> My suggestion is to require either "iat" or "nbf". That shouldn't break anything, and deployments that rely on one or the other to determine the validity window of the access token can continue using their preferred claim for that.
>>> 
>>> Vladimir
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf..org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> _______________________________________________ 
>> OAuth mailing list 
>> OAuth@ietf.org <mailto:OAuth@ietf.org> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>