Re: [OAUTH-WG] JWT compares client time with server time

Thomas Broyer <t.broyer@gmail.com> Fri, 22 January 2016 16:05 UTC

Return-Path: <t.broyer@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AE21AD289 for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 08:05:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 YtQtT_KI-fBQ for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 08:05:21 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (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 9173A1AD277 for <oauth@ietf.org>; Fri, 22 Jan 2016 08:05:20 -0800 (PST)
Received: by mail-lb0-x22f.google.com with SMTP id x4so44085318lbm.0 for <oauth@ietf.org>; Fri, 22 Jan 2016 08:05:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=fsQuwy0V839A5AhYf/Cq9cboIewbAbMN16JJWYEiWIQ=; b=G44wRu7CwtrWEDesKw1Vrnm6Zn2G+IrwJMb2AV+oVGzoDOEcjvQ+Sbix6hygIUpNu/ Cr9WGMuITlLJZxGI+bhVZTSKf/bino9VX3VNcOMqK/v7/dFYw2RRD8utvLvFG4SZ02rQ A1qCJU1OPeR+Bc9hSsM6wwbtdSSDLZ0ByOaHpZY8iFtvdeUDvN97za9zkrkje4vfE7lg cb8/VnSr7e+C2+SpoMIdfmvTDOJucCQL65l+N0gR1SCTvBMHH2UvnyoWExVD17yL9yq4 RU7EUIdIOAuuFap4eVidRiSYAcRlA3HKSs6evWyN2LV0IMMNOv3TdM6yKrCAX/OKCHb9 KbHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=fsQuwy0V839A5AhYf/Cq9cboIewbAbMN16JJWYEiWIQ=; b=AD7ee4RGjMpgNrvYRk23km8jNZDwU3t6RJXC5nPfZIq7QmvfDdn4Bf7ivawDT8vsEs rJ2ye2BOcTiQt90Gh64Sz9GpWhCaRM58hKaor2NhFjmcoQrVL5ge0cn40Alews8LFp/w Gt5Pp6maSpUJvBD1rSi4pyBwdPZ1yROFb5cGS0wWcnjOMMA3cLACc9MMcQYaizz10iJK gTpDhn9NYsJV9Ty2K16u4yhnVVuMDrQPWknFcGscoad64QilgCyzw583YXVc7bgNytN+ LDu3zNpJVnAIOqxEmxMnFqUMmSRDbKGB0jESjvSNcNRTcTVwnWaHWmgrYtPMvHPkcgCJ T3vg==
X-Gm-Message-State: AG10YOT47X/2z2ZgACvutIRy0CT8BqmgNrly3ZKwMUR244jCOpf4q1Wd0xq0VQOGbsCgeX2Xz0H5UwRTYpygaw==
X-Received: by 10.112.35.162 with SMTP id i2mr1502186lbj.107.1453478718750; Fri, 22 Jan 2016 08:05:18 -0800 (PST)
MIME-Version: 1.0
References: <56A171E9.6060705@bucksch.org>
In-Reply-To: <56A171E9.6060705@bucksch.org>
From: Thomas Broyer <t.broyer@gmail.com>
Date: Fri, 22 Jan 2016 16:05:08 +0000
Message-ID: <CAEayHEM2AKr20AxRDuABm=XUAE_3TS=TK27FaUcjT3hCHOcUnA@mail.gmail.com>
To: Ben Bucksch <news@bucksch.org>, oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a11c36b66b84fb10529ee624f
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/AHXhTs5bYDWbPtQCTwFRwyWy0nA>
Subject: Re: [OAUTH-WG] JWT compares client time with server time
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 22 Jan 2016 16:05:23 -0000

Or just account for clock differences when comparing values, which I
believe is what the specs suggest.

Le ven. 22 janv. 2016 15:50, Ben Bucksch <news@bucksch.org> a écrit :

> Story: We wrote a script implementing JWT.
>
> The code was working for my colleague, who wrote the script, but I just
> got "Invalid authentication credentials".
>
> We were debugging it for days (!), suspecting shell argument passing and
> parsing, OS differences and what not. We compared credentials and
> confirmed they are identical. Still, the result was different. During
> debugging, once, by coincidence, it worked - at a time when it should be
> expired.
>
> What was the reason? My clock on my computer was fast.
>
> I was speechless. Client/server protocols must NEVER compare client
> clocks with server clocks, because clocks are very often off. Even if it
> was originally set exactly right by the second, clocks always have a
> drift in one way or another. If you have 5 million users, you will
> surely have 500000 whose clocks are off by 1 minute, and 50000 users
> whose clocks are off more than that.
> In my case, my clock was 95 seconds fast. That's not uncommon. You
> cannot expect nor demand that every computer in the world runs NTP clients.
>
> OAuth 2.0 knows that and does not rely on client clock matching server
> clock. For good reason. Ditto HTTP Cache headers don't send client time,
> even though that's an obvious and simple implementation, but the server
> sends and ETag and the client echos it back. Even if that's a more
> complex implementation, it's crucial to work reliably.
>
> ------------------------------------------------------------------------
>
> Worse, in JWT, iat (time of issue, created by JWT client) is often
> enforced with second precision on the JWT server. A client clock that is
> just 3 seconds fast (very likely) will cause an iat in the future, which
> makes the server reject it.
>
> You simply cannot compare client clock with server clocks. Please change
> the protocol to not do that, or take JWT off the proposed standards track.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>