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

John Bradley <ve7jtb@ve7jtb.com> Fri, 22 January 2016 16:39 UTC

Return-Path: <ve7jtb@ve7jtb.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 42FFA1B29B3 for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 08:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 5NoU2iTpXoPg for <oauth@ietfa.amsl.com>; Fri, 22 Jan 2016 08:39:15 -0800 (PST)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 1A0E61B29C8 for <oauth@ietf.org>; Fri, 22 Jan 2016 08:39:15 -0800 (PST)
Received: by mail-qg0-x236.google.com with SMTP id b35so61236767qge.0 for <oauth@ietf.org>; Fri, 22 Jan 2016 08:39:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=jDApSJ/mwpVWZI7/1WaEG1Fd/xYRxv5y+ISEqo0GhAc=; b=Q8Za4idjIaZ6V2fu6x290EMk7hORzFzK0lc/YAgR2iZpfW3flZirGISBbIM+WX/gMS aU4RJuv0Tm9xrXakAfAM0bB5eOULMbc5I85266O2MwXpsehGyELwiy80il9VNAUedsNT wmzu9JTcBy4KbPOHeURXMXJUR6AhDcYvSwhAxlJBFw0HQlqGXzVDyYnxJlfmKHu7Fq8B f0jH3mn6LPHjeT0dZFwPXbJ1Zr1tjQ3nbVH0hs1j1yQKQJPuQgMCrp4zuL5ar32MOnb3 4n2IEvHHqJq2iJk6KHcR89hBYrkmgIrcxqBY+W0MrOtE7qavV+qXIdwb7lL4uk9xZEW4 vyLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=jDApSJ/mwpVWZI7/1WaEG1Fd/xYRxv5y+ISEqo0GhAc=; b=Ec1d2OeCkHnRCyVL1naz8oSuwAg0LVj00e4G++YSeK6q137O0S+PnNLrzmcKCGElgY 1k6LeEHO8q6aQy3rABDsljjvRUDyF80+vwYvVkRD1jfp/k4BK8OROlsIlicpZg97d/Rd cZMUZumm9AFraIl2E+jTHGLLJBCXbVMVb8JSbzZE+xMl76Nna8cZrCzM7I2Sp5D8eqpx yMAmuK37KILtJD/ihHlXA584WY461zCLR7RMgR5/1BvWrr4u+PTOeVOPzecTsu6VOYc4 dirwtACGDIhyd1+l1fB2a5axE7V3RkqkhQlSNCq7qOwpXcx7M5+7B83ev/SlcSUJbnN1 +oBg==
X-Gm-Message-State: AG10YOQrivEKPQIk/dVc3/jbvqydNTiSLG+VRi6X3vr7WZ3NKClFgxFiy2LDuumklostjg==
X-Received: by 10.140.226.8 with SMTP id w8mr5117644qhb.83.1453480754105; Fri, 22 Jan 2016 08:39:14 -0800 (PST)
Received: from [192.168.8.100] ([181.202.234.84]) by smtp.gmail.com with ESMTPSA id v65sm3038512qhc.46.2016.01.22.08.39.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 08:39:13 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8CB6183F-AD4B-44CC-9149-1BDEE688DB4C"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <56A171E9.6060705@bucksch.org>
Date: Fri, 22 Jan 2016 13:39:09 -0300
Message-Id: <C5780AE9-BFD5-4A39-BB3F-08C36D936E4F@ve7jtb.com>
References: <56A171E9.6060705@bucksch.org>
To: Ben Bucksch <news@bucksch.org>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/UB867WNZp1IO9lA4kyokirZbHuE>
Cc: oauth@ietf.org
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:39:17 -0000

Sorry to hear about your debugging trouble.

JWT is a security token format, a bit like SAML.

It has “iat” (issued at) as one of the optional claims that a protocol can use.
It is defined similarly to IssueInstant in SAML.

It is the protocols that use JWT that need to define the comparison rules, the value is what it is, and a receiver needs to  accommodate clock drift in both cases.

OAuth is just starting to define a JWT access token for PoP.  https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution
That has iat in the example but nothing calling it out in the validation rules at the RS.   That is something I will note.

OpenID Connect defines the use of iat in id_tokens

	• The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.

In that case it is used to manage the cache for replay protection.

For exp we do note in Connect:
	• The current time MUST be before the time represented by the exp Claim (possibly allowing for some small leeway to account for clock skew).

It is not clear from your email what protocol you are trying to use JWT in.

At the JWT level we don’t know what a protocol is going to use iat for so specific advice on managing clock skew is difficult.

Regards
John B.


> On Jan 21, 2016, at 9:03 PM, Ben Bucksch <news@bucksch.org> wrote:
> 
> 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