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

From: Mike Jones <[email-masked]>
Date: Fri, 24 Aug 2012 23:02:55 +0000

I'll note for discussion purposes that a nonce and a timestamp are not the same thing (although sometimes they are used to achieve similar/related goals).  A nonce tends to be an opaque value that must be preserved across the communication.  Whereas a timestamp typically has defined semantics - sometimes simply a non-decreasing integer value - and sometimes a representation of time, and then, sometimes with a uniqueness requirement.

For discussion purposes, I'll say that the simplest thing for us to do (should we decide to do anything in this regard) would be to define the nonce as an opaque string value that must be preserved.

We could also define a timestamp parameter, but as I wrote above, that would likely require us to specify additional semantics - starting with whether it's a non-decreasing integer or a representation of a time value.  This seems much harder to define and possibly to use than a nonce.

Would it make sense to define a nonce parameter now and hold off on defining a timestamp parameter until there's a clear demonstrated use case for which a nonce is not sufficient?  That would be my personal recommendation.

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 12: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: Justin Richer <[email-masked]>
Date: Mon, 27 Aug 2012 10:58:53 -0400

How is "issued at" not a timestamp?

  -- Justin

---

From: Mike Jones <[email-masked]>
Date: Mon, 27 Aug 2012 18:11:51 +0000

It is.  For those of you wondering what the reference to "issued at" is, see http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1.3.

				-- Mike

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Monday, August 27, 2012 7:59 AM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

  -- Justin

---

From: Axel Nennker <[email-masked]>
Date: Sat, 25 Aug 2012 09:37:41 +0200

To clarify: What is the base specification that Jim mentioned?
Is it: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ?

Would somebody please present a use-case for either nonce or timestamp?
If a jwt is used with oauth2 then what is the difference between nonce and
state? Nonce would be signed while state is not?

I guess I am missing some information that those in the room who voted
"yes" had?

Axel

2012/8/25 Mike Jones <[email-masked]>

> I'll note for discussion purposes that a nonce and a timestamp are not the
> same thing (although sometimes they are used to achieve similar/related
> goals).  A nonce tends to be an opaque value that must be preserved across
> the communication.  Whereas a timestamp typically has defined semantics -
> sometimes simply a non-decreasing integer value - and sometimes a
> representation of time, and then, sometimes with a uniqueness requirement.
>
> For discussion purposes, I'll say that the simplest thing for us to do
> (should we decide to do anything in this regard) would be to define the
> nonce as an opaque string value that must be preserved.
>
> We could also define a timestamp parameter, but as I wrote above, that
> would likely require us to specify additional semantics - starting with
> whether it's a non-decreasing integer or a representation of a time value.
>  This seems much harder to define and possibly to use than a nonce.
>
> Would it make sense to define a nonce parameter now and hold off on
> defining a timestamp parameter until there's a clear demonstrated use case
> for which a nonce is not sufficient?  That would be my personal
> recommendation.
>
>                                 Best wishes,
>                                 -- Mike
>
> 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.
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 Aug 2012 10:32:50 -0400

On 08/25/2012 03:37 AM, Axel Nennker wrote:
> If a jwt is used with oauth2 then what is the difference between nonce 
> and state? Nonce would be signed while state is not?
>

Nonce would generally be generated by the entity creating the token. 
State in OAuth is generated by the client, and would only be protected 
if the client had a means to make a signed request to the server, using 
either a MAC binding or a JWT-based OIDC-style RequestObject.

  -- Justin

> 2012/8/25 Mike Jones <[email-masked] 
> <mailto:[email-masked]>>
>
>     I'll note for discussion purposes that a nonce and a timestamp are
>     not the same thing (although sometimes they are used to achieve
>     similar/related goals).  A nonce tends to be an opaque value that
>     must be preserved across the communication.  Whereas a timestamp
>     typically has defined semantics - sometimes simply a
>     non-decreasing integer value - and sometimes a representation of
>     time, and then, sometimes with a uniqueness requirement.
>
>     For discussion purposes, I'll say that the simplest thing for us
>     to do (should we decide to do anything in this regard) would be to
>     define the nonce as an opaque string value that must be preserved.
>
>     We could also define a timestamp parameter, but as I wrote above,
>     that would likely require us to specify additional semantics -
>     starting with whether it's a non-decreasing integer or a
>     representation of a time value.  This seems much harder to define
>     and possibly to use than a nonce.
>
>     Would it make sense to define a nonce parameter now and hold off
>     on defining a timestamp parameter until there's a clear
>     demonstrated use case for which a nonce is not sufficient?  That
>     would be my personal recommendation.
>
>                                     Best wishes,
>                                     -- Mike
>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of Jim Schaad
>     To: [email-masked] <mailto:[email-masked]>
>     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.
>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

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

In OAuth 2 state gets overloaded with a bunch of things from preventing XSRF to providing a handle to look up who the the authorization request was sent to.

In Connect we added a nonce sent by client that is returned inside the signed id_token (JWT) to allow the client to detect replay, and optionally reference a specific browser session that presents the id_token.

The nonce I suggested for JOSE is not ether of those.  

I used nonce in the sense that it is used with stream cyphers when the same key is used over multiple messages.

JOSE will be used for more than OAuth and JWT.   There are cases where adding entropy to the header will be a security benefit.  I would like to have a standard claim for doing that.
If people want to call it something else that is fine, but it is a nonce by definition.
If used it should be a random or pseudo random value that is time variant with sufficient granularity to ensure a nonce is used only once.

John B.

On 2012-08-28, at 10:32 AM, Justin Richer <[email-masked]> wrote:

>> If a jwt is used with oauth2 then what is the difference between nonce and state? Nonce would be signed while state is not?
>> 
> 
> Nonce would generally be generated by the entity creating the token. State in OAuth is generated by the client, and would only be protected if the client had a means to make a signed request to the server, using either a MAC binding or a JWT-based OIDC-style RequestObject.
> 
>  -- Justin
> 
>> I guess I am missing some information that those in the room who voted "yes" had?
>> 
>> Axel
>>

---

From: Breno de Medeiros <[email-masked]>
Date: Tue, 28 Aug 2012 12:06:33 -0700

I agree that this should be looked independently of oauth2.

Nonce is a generally used concept in crypto, though sometimes protocol
designers have called for nonces with bad outcomes because the difficulty
of implementing nonce-checking was disregarded. However, difficulties to
implement nonces in general are not relevant if there is a compelling use
case that is able to leverage nonces effectively.

As for timestamps: we already have issued time and the nonce can embed a
timestamp additionally. So I don't think we need to concern ourselves with
timestamps when considering nonces.

On Tue, Aug 28, 2012 at 8:09 AM, John Bradley <[email-masked]> wrote:

> In OAuth 2 state gets overloaded with a bunch of things from preventing
> XSRF to providing a handle to look up who the the authorization request was
> sent to.
>
> In Connect we added a nonce sent by client that is returned inside the
> signed id_token (JWT) to allow the client to detect replay, and optionally
> reference a specific browser session that presents the id_token.
>
> JOSE will be used for more than OAuth and JWT.   There are cases where
> adding entropy to the header will be a security benefit.  I would like to
> have a standard claim for doing that.
> If used it should be a random or pseudo random value that is time variant
> with sufficient granularity to ensure a nonce is used only once.
>
> John B.
>
> Nonce would generally be generated by the entity creating the token. State
> in OAuth is generated by the client, and would only be protected if the
> client had a means to make a signed request to the server, using either a
> MAC binding or a JWT-based OIDC-style RequestObject.
>
>  -- Justin
>
>> I'll note for discussion purposes that a nonce and a timestamp are not
>> the same thing (although sometimes they are used to achieve similar/related
> jose mailing [email-masked]://www.ietf.org/mailman/listinfo/jose
>
>

-- 
--Breno

---

From: Brian Campbell <[email-masked]>
Date: Tue, 28 Aug 2012 14:46:06 -0600

Isn't the pool question really about JOSE (this is the JOSE list after all)
and if a nonce or timestamp type thing should be defined in JWE/JWS as a
Reserved Header Parameter Name?

I don't think it can be said that we already have an issued time defined.
"iat" (Issued At) is a claim defined in JWT. That's all together a
different thing than a JOSE header and I don't see anything like it
anywhere in the JOSE docs. JWT is a layer above JOSE and, while there is a
lot of overlap of people, is being developed in a completely different WG.

I'm, at this point, saying we need this thing but rather just trying to
clarify the question.

On Tue, Aug 28, 2012 at 1:06 PM, Breno de Medeiros <[email-masked]> wrote:

>> State in OAuth is generated by the client, and would only be protected if
>> the client had a means to make a signed request to the server, using either
>> a MAC binding or a JWT-based OIDC-style RequestObject.
>>
>>  -- Justin
>>
>>> 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.
>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 Aug 2012 17:14:28 -0400

So the obvious question (to me) is whether or not the claim should move 
to the JOSE layer.

  -- Justin

On 08/28/2012 04:46 PM, Brian Campbell wrote:
> Isn't the pool question really about JOSE (this is the JOSE list after 
> all) and if a nonce or timestamp type thing should be defined in 
> JWE/JWS as a Reserved Header Parameter Name?
>
> I don't think it can be said that we already have an issued time 
> defined. "iat" (Issued At) is a claim defined in JWT. That's all 
> together a different thing than a JOSE header and I don't see anything 
> like it anywhere in the JOSE docs. JWT is a layer above JOSE and, 
> while there is a lot of overlap of people, is being developed in a 
> completely different WG.
>
> I'm, at this point, saying we need this thing but rather just trying 
> to clarify the question.
>
> On Tue, Aug 28, 2012 at 1:06 PM, Breno de Medeiros <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Nonce is a generally used concept in crypto, though sometimes
>     protocol designers have called for nonces with bad outcomes
>     because the difficulty of implementing nonce-checking was
>     disregarded. However, difficulties to implement nonces in general
>     are not relevant if there is a compelling use case that is able to
>     leverage nonces effectively.
>
>     As for timestamps: we already have issued time and the nonce can
>     embed a timestamp additionally. So I don't think we need to
>     concern ourselves with timestamps when considering nonces.
>
>
>
>
>     On Tue, Aug 28, 2012 at 8:09 AM, John Bradley <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         In OAuth 2 state gets overloaded with a bunch of things from
>         preventing XSRF to providing a handle to look up who the the
>         authorization request was sent to.
>
>         In Connect we added a nonce sent by client that is returned
>         inside the signed id_token (JWT) to allow the client to detect
>         replay, and optionally reference a specific browser session
>         that presents the id_token.
>
>         I used nonce in the sense that it is used with stream cyphers
>         when the same key is used over multiple messages.
>
>         JOSE will be used for more than OAuth and JWT.   There are
>         cases where adding entropy to the header will be a security
>         benefit.  I would like to have a standard claim for doing that.
>         If used it should be a random or pseudo random value that is
>         time variant with sufficient granularity to ensure a nonce is
>         used only once.
>
>         John B.
>
>         On 2012-08-28, at 10:32 AM, Justin Richer <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>>>         Is it:
>>>         http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03 ?
>>>
>>>         If a jwt is used with oauth2 then what is the difference
>>>         between nonce and state? Nonce would be signed while state
>>>         is not?
>>>
>>
>>         Nonce would generally be generated by the entity creating the
>>         token. State in OAuth is generated by the client, and would
>>         only be protected if the client had a means to make a signed
>>         request to the server, using either a MAC binding or a
>>         JWT-based OIDC-style RequestObject.
>>
>>          -- Justin
>>
>>>             I'll note for discussion purposes that a nonce and a
>>>             timestamp are not the same thing (although sometimes
>>>             they are used to achieve similar/related goals).  A
>>>             nonce tends to be an opaque value that must be preserved
>>>             across the communication.  Whereas a timestamp typically
>>>             has defined semantics - sometimes simply a
>>>             non-decreasing integer value - and sometimes a
>>>             For discussion purposes, I'll say that the simplest
>>>             thing for us to do (should we decide to do anything in
>>>             this regard) would be to define the nonce as an opaque
>>>             string value that must be preserved.
>>>
>>>             We could also define a timestamp parameter, but as I
>>>             wrote above, that would likely require us to specify
>>>             additional semantics - starting with whether it's a
>>>             non-decreasing integer or a representation of a time
>>>             value.  This seems much harder to define and possibly to
>>>             use than a nonce.
>>>
>>>             Would it make sense to define a nonce parameter now and
>>>             hold off on defining a timestamp parameter until there's
>>>             a clear demonstrated use case for which a nonce is not
>>>             sufficient?  That would be my personal recommendation.
>>>
>>>             Best wishes,
>>>             -- Mike
>>>
>>>             [mailto:[email-masked]
>>>             <mailto:[email-masked]>] On Behalf Of Jim Schaad
>>>             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.
>>>