Re: [jose] DISCUSS: Nonce/Timestamp parameter

[Justin Richer <[e-mail]>]

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 <[e-mail] 
> <mailto:[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]
>     <mailto:[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]
>         <mailto:[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]
>>>         <mailto:[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]>
>>>             [mailto:[e-mail]
>>>             <mailto:[e-mail]>] On Behalf Of Jim Schaad
>>>             Sent: Friday, August 17, 2012 12:05 AM
>>>             To: [e-mail] <mailto:[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] <mailto:[e-mail]>
>>>             https://www.ietf.org/mailman/listinfo/jose
>>>
>>>
>>>             _______________________________________________
>>>             jose mailing list
>>>             [e-mail] <mailto:[e-mail]>
>>>             https://www.ietf.org/mailman/listinfo/jose
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         jose mailing list
>>>         [e-mail]  <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/jose
>>
>>         _______________________________________________
>>         jose mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/jose
>
>
>         _______________________________________________
>         jose mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/jose
>
>
>
>
>     -- 
>     --Breno
>
>
>     _______________________________________________
>     jose mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/jose
>
>