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
Precedence: list

--001a11c36b66b84fb10529ee624f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 =C3=A9crit :

> 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 client=
s.
>
> 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
>

--001a11c36b66b84fb10529ee624f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Or just account for clock differences when comparing values,=
 which I believe is what the specs suggest.<br>
</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0ven. 22 janv. 2016 =
15:50,=C2=A0Ben Bucksch &lt;<a href=3D"mailto:news@bucksch.org">news@bucksc=
h.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">S=
tory: We wrote a script implementing JWT.<br>
<br>
The code was working for my colleague, who wrote the script, but I just<br>
got &quot;Invalid authentication credentials&quot;.<br>
<br>
We were debugging it for days (!), suspecting shell argument passing and<br=
>
parsing, OS differences and what not. We compared credentials and<br>
confirmed they are identical. Still, the result was different. During<br>
debugging, once, by coincidence, it worked - at a time when it should be<br=
>
expired.<br>
<br>
What was the reason? My clock on my computer was fast.<br>
<br>
I was speechless. Client/server protocols must NEVER compare client<br>
clocks with server clocks, because clocks are very often off. Even if it<br=
>
was originally set exactly right by the second, clocks always have a<br>
drift in one way or another. If you have 5 million users, you will<br>
surely have 500000 whose clocks are off by 1 minute, and 50000 users<br>
whose clocks are off more than that.<br>
In my case, my clock was 95 seconds fast. That&#39;s not uncommon. You<br>
cannot expect nor demand that every computer in the world runs NTP clients.=
<br>
<br>
OAuth 2.0 knows that and does not rely on client clock matching server<br>
clock. For good reason. Ditto HTTP Cache headers don&#39;t send client time=
,<br>
even though that&#39;s an obvious and simple implementation, but the server=
<br>
sends and ETag and the client echos it back. Even if that&#39;s a more<br>
complex implementation, it&#39;s crucial to work reliably.<br>
<br>
------------------------------------------------------------------------<br=
>
<br>
Worse, in JWT, iat (time of issue, created by JWT client) is often<br>
enforced with second precision on the JWT server. A client clock that is<br=
>
just 3 seconds fast (very likely) will cause an iat in the future, which<br=
>
makes the server reject it.<br>
<br>
You simply cannot compare client clock with server clocks. Please change<br=
>
the protocol to not do that, or take JWT off the proposed standards track.<=
br>
<br>
_______________________________________________<br>
OAuth mailing list<br>
<a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/oauth" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br>
</blockquote></div>

--001a11c36b66b84fb10529ee624f--