Re: [jose] DISCUSS: Nonce/Timestamp parameter

[Brian Campbell <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]> 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.
>>
>> 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 <[e-mail]> wrote:
>>
>>  On 08/25/2012 03:37 AM, Axel Nennker wrote:
>>
>> 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?
>>
>>
>> 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
>>
>> 2012/8/25 Mike Jones <[e-mail]>
>>
>>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Jim Schaad
>>> Sent: Friday, August 17, 2012 12:05 AM
>>> To: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>
>>
>>
>> _______________________________________________
>> jose mailing [e-mail]://www.ietf.org/mailman/listinfo/jose
>>
>>
>>  _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>>
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>
>
> --
> --Breno
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>