Re: [jose] DISCUSS: Nonce/Timestamp parameter

"Jim Schaad" <ietf@augustcellars.com> Wed, 29 August 2012 03:40 UTC

Return-Path: <ietf@augustcellars.com>
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 A8C9121F841A for <jose@ietfa.amsl.com>; Tue, 28 Aug 2012 20:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.446
X-Spam-Level:
X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, 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 uqtF7yv1-kTl for <jose@ietfa.amsl.com>; Tue, 28 Aug 2012 20:40:14 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2921F841C for <jose@ietf.org>; Tue, 28 Aug 2012 20:40:14 -0700 (PDT)
Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id D56FC2C9F4; Tue, 28 Aug 2012 20:40:12 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Dick Hardt' <dick.hardt@gmail.com>, Axel.Nennker@telekom.de
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> <CE8995AB5D178F44A2154F5C9A97CAF402517E00C107@HE111541.emea1.cds.t-internal.com> <97A7AE3F-E3AE-4F8A-9A34-8DCD780B3C05@gmail.com>
In-Reply-To: <97A7AE3F-E3AE-4F8A-9A34-8DCD780B3C05@gmail.com>
Date: Tue, 28 Aug 2012 20:38:20 -0700
Message-ID: <05f101cd8597$cff358c0$6fda0a40$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05F2_01CD855D.239718D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQG+fWRNYMYi661kYmFSaxgdrCg93gEzurJ7AjUoCs0BvUKSxAIEi9JxArm+c1MCJORRUZctGIvg
Content-Language: en-us
Cc: beaton@google.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: Wed, 29 Aug 2012 03:40:16 -0000

The question from my point of view is that common fields from many
structures should potentially be supported in the base specification so that
they can be common rather than having each structure define them separately.
This is only an issue if one wishes them to be placed in the header
structure and not in the data structure.  

 

If one is looking at signing an unstructured data object - such as a file -
then it becomes difficult to have the fields such as a time that it was
signed be part of the file itself, especially if one is applying multiple
signatures at different times.  This is not an issue for the token
specification but could be for other uses of the signature or encryption
specifications.

 

I would agree that "iat" is a timestamp for the purposes of this
conversation.  If one wanted a formalized timestamp from a third party
authority then a totally different way of going about it would be required.
I chose the term nonce or timestamp because both had been discussed in the
past without any specific resolution about what is needed.

 

Jim

 

 

From: Dick Hardt [mailto:dick.hardt@gmail.com] 
Sent: Monday, August 27, 2012 2:55 PM
To: Axel.Nennker@telekom.de
Cc: dick.hardt@gmail.com; beaton@google.com; ietf@augustcellars.com;
jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

I was considering "iat" to be the timestamp. I was not thinking there would
be an additional timestamp.

 

On Aug 27, 2012, at 2:13 PM, <Axel.Nennker@telekom.de> wrote:





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> 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.