IETF Logo Mail Archive

Re: [jose] DISCUSS: Nonce/Timestamp parameter

<Axel.Nennker@telekom.de> Mon, 27 August 2012 21:13 UTC

Return-Path: <Axel.Nennker@telekom.de>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC3C21F8518 for <jose@ietfa.amsl.com>; Mon, 27 Aug 2012 14:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level:
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAaAmfJmWuom for <jose@ietfa.amsl.com>; Mon, 27 Aug 2012 14:13:18 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3B21F8501 for <jose@ietf.org>; Mon, 27 Aug 2012 14:13:17 -0700 (PDT)
Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 27 Aug 2012 23:13:15 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Mon, 27 Aug 2012 23:13:15 +0200
From: Axel.Nennker@telekom.de
To: dick.hardt@gmail.com, beaton@google.com
Date: Mon, 27 Aug 2012 23:13:09 +0200
Thread-Topic: [jose] DISCUSS: Nonce/Timestamp parameter
Thread-Index: Ac2Ekc1v3q3i0xfJQVyqbmnlKPELkQABuOGg
Message-ID: <CE8995AB5D178F44A2154F5C9A97CAF402517E00C107@HE111541.emea1.cds.t-internal.com>
References: <CE8995AB5D178F44A2154F5C9A97CAF402517E00B8B5@HE111541.emea1.cds.t-internal.com> <CE8995AB5D178F44A2154F5C9A97CAF402517E00C0E7@HE111541.emea1.cds.t-internal.com> <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> <CALT9B_Tnz+9=a-NPuUTeSb31fFMi1cJMB-SeM7QJmSh=XrhHTA@mail.gmail.com> <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com>
In-Reply-To: <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402517E00C107HE111541eme_"
MIME-Version: 1.0
Cc: ietf@augustcellars.com, jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2012 21:13:18 -0000

We have exp

                https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.1

and iat

                https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.3

in JWT. Why do we need a timestamp?



Replay attacks of the same jwt can be mitigated through the jti claim

https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.7



What do timestamp and nonce add to these?



Axel




From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Monday, August 27, 2012 10:23 PM
To: Brian Eaton
Cc: Nennker, Axel; Jim Schaad; jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter


On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote:


On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <dick.hardt@gmail.com<mailto:dick.hardt@gmail.com>> wrote:
I have an application for JWT that is not OAuth2.

Should nonce and timestamp logic go in the application level protocol?

I prefer to NOT have the application level deal with token validity.



Having said that, nonce's are difficult to implement at scale and I have heard of many sites that don't implement them fully.

Nonce alone can't be implemented efficiently.  You have to have time stamps as well, otherwise you are stuck storing ever nonce you've ever seen, forever.

Even nonce + time stamp is challenging in distributed systems.  It adds a lot of complexity.  That complexity is sometimes merited, but not always.

Thanks for confirming my statement.

I have stopped using nonce and only use time stamps lately and have made the system relatively stateless so that a second submission of the token is ok. That may not work for everyone, but I have found that architecture to be easier to implement and scale.

v2.43.4 | Report a Bug | By Email | System Status