Return-Path: 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 9FD7C11E80E7 for ; Tue, 28 Aug 2012 14:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 w8mzNE7-KfLe for ; Tue, 28 Aug 2012 14:16:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7AED511E80A5 for ; Tue, 28 Aug 2012 14:16:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BFBC221B0C2D; Tue, 28 Aug 2012 17:16:00 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9840A21B08A0; Tue, 28 Aug 2012 17:16:00 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 28 Aug 2012 17:16:00 -0400 Message-ID: <503D34B4.9040606@mitre.org> Date: Tue, 28 Aug 2012 17:14:28 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Campbell References: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> <503CD692.4020007@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010303090806060809000209" X-Originating-IP: [129.83.31.58] Cc: Axel Nennker , Jim Schaad , Breno de Medeiros , Mike Jones , "jose@ietf.org" , John Bradley 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 21:16:04 -0000 --------------010303090806060809000209 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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 > 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 > 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 > 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 >> > >>> >>> 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: jose-bounces@ietf.org >>> >>> [mailto:jose-bounces@ietf.org >>> ] On Behalf Of Jim Schaad >>> Sent: Friday, August 17, 2012 12:05 AM >>> To: jose@ietf.org >>> Subject: [jose] POLL: Nonce/Timestamp parameter >>> >>> >>> >>> 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 >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > -- > --Breno > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --------------010303090806060809000209 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
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 <breno@google.com> 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 <ve7jtb@ve7jtb.com> 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 <jricher@mitre.org> 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 <Michael.Jones@microsoft.com>
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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, August 17, 2012 12:05 AM
To: jose@ietf.org
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
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose



_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose




--
--Breno


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose



--------------010303090806060809000209--