Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

From: <[email-masked]>
Date: Mon, 27 Aug 2012 10:37:21 +0200

What is the base specification? https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ?
I think that nonce and timestamp are protocol specific fields and that JOSE is not about protocols. There are no round-trips in JOSE.
The cryptographic algorithms used in JOSE are secure enough without nounce and timestamp.

Axel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 9:05 AM
To: [email-masked]
Subject: [jose] POLL: Nonce/Timestamp parameter

<CHAIR>

If you voted at the face-2-face please do not vote again.  If you want to provide comments please change the title from POLL to DISCUSS.

Do we need to define a nonce/timestamp parameter in the base specification?

Room vote:  6 yes, 0 no, 1 discuss

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: <[email-masked]>
Date: Mon, 27 Aug 2012 21:06:03 +0200

I vote: NO

I think that nonce does make sense in signing or encryption because it only makes sense in a protocol exchange. 
Maybe there is some justification for nonce in jwt but if jwt is used with oauth2 then we already have state.

Could one of the six who voted yes please explain why nonce is useful?

Axel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nennker, Axel
Sent: Monday, August 27, 2012 10:37 AM
To: [email-masked]; [email-masked]
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

Axel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 9:05 AM
To: [email-masked]
Subject: [jose] POLL: Nonce/Timestamp parameter

<CHAIR>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Aug 2012 12:11:35 -0700

I have an application for JWT that is not OAuth2. 

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

---

From: Brian Eaton <[email-masked]>
Date: Mon, 27 Aug 2012 13:06:19 -0700

> I have an application for JWT that is not OAuth2.

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

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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Aug 2012 13:23:01 -0700

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

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

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

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 27 Aug 2012 21:02:57 +0000

Depends on what the nonce is used for as if this is for key entropy then I would say there is very little overhead and storage issues and in this case I would expect the header to contain the nonce, if it's for state of some sort then I would expect it at the application level and  not as a header and more of a JWT claim.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: Monday, August 27, 2012 1:06 PM
To: Dick Hardt
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
I have an application for JWT that is not OAuth2.

---

From: <[email-masked]>
Date: Mon, 27 Aug 2012 23:13:09 +0200

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:[email-masked]]
Sent: Monday, August 27, 2012 10:23 PM
To: Brian Eaton
Cc: Nennker, Axel; Jim Schaad; [email-masked]
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

---

From: Mike Jones <[email-masked]>
Date: Mon, 27 Aug 2012 21:36:02 +0000

Just to complete the picture, I'll also add that OpenID Connect defines a nonce claim (at the JWT claim level, rather than the JOSE header parameter level).

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 27, 2012 2:13 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

We have exp

and iat

Axel

From: Dick Hardt [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, August 27, 2012 10:23 PM
To: Brian Eaton
Cc: Nennker, Axel; Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Aug 2012 14:54:58 -0700

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Aug 2012 00:19:36 -0400

Axel,

I did not vote on this issue, but I am concerned by what appears to be 
the basis for your
position. Specifically, you say:

*Maybe there is some justification for nonce in jwt but if jwt is used 
with oauth2 then we already have state.*

JOSE's cope is not just oauth2, so it seems inappropriate to argue that 
a feature is not
needed based on just that app.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Aug 2012 00:27:14 -0400

Brian,

...

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.

In general how long one needs to retain a nonce depends on how the nonce 
is used. But I agree
that using timestamps and plus nonces together helps.

Steve

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Aug 2012 11:29:12 +0700

Steve: That depends on how the nonce is being used, right? 

All: This sort of confusion is a good example of how underspecified this question is.  Does anyone understand the question well enough to re-phrase more clearly?  

-- 
Richard Barnes
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Tuesday, August 28, 2012 at 11:27 AM, Stephen Kent wrote:

> [email-masked] (mailto:[email-masked])

---

From: <[email-masked]>
Date: Tue, 28 Aug 2012 06:30:13 +0200

I agree that jwt is  useful without oauth2.
Still we already have exp, iat, jti in jwt.
What protection do nonce/timestamp bring to jwt users?

I think the poll about this question should be reconsidered because the question is unclear and nonce/timestamp have no supporting use case beyond exp, iat, jti.

Axel

From: Stephen Kent [mailto:[email-masked]]
Sent: Tuesday, August 28, 2012 6:20 AM
To: [email-masked]; Nennker, Axel
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

Axel,

I did not vote on this issue, but I am concerned by what appears to be the basis for your
position. Specifically, you say:

JOSE's cope is not just oauth2, so it seems inappropriate to argue that a feature is not
needed based on just that app.

Steve

---

From: John Bradley <[email-masked]>
Date: Tue, 28 Aug 2012 10:46:11 -0400

There are attacks that we have seen in the past that are possible if the attacker can predict the header and control what is signed in the body.

Perhaps nonce is not the best name for it.   People seem to have kept to the conclusion that it is used to maintain session state between parties.

I raised it as a standard place to add per message entropy, as JOSE doesn't control the content of the body.
I was not saying that it is required, it is not in cases where the signer is producing the body without external input.

It is intended as a optional claim who's value may not be processed by the receiver at all. 

Some applications might code something into the nonce, or use it to prevent replay, that was however not my primary intent.

John B.

On 2012-08-27, at 5:02 PM, Anthony Nadalin <[email-masked]> wrote:

> Depends on what the nonce is used for as if this is for key entropy then I would say there is very little overhead and storage issues and in this case I would expect the header to contain the nonce, if it’s for state of some sort then I would expect it at the application level and  not as a header and more of a JWT claim.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 28 Aug 2012 20:38:20 -0700

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:[email-masked]] 
Sent: Monday, August 27, 2012 2:55 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
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.

We have exp

and iat

Axel

 

 

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.