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 1130711E80A5 for ; Tue, 28 Aug 2012 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jJsSMyERBvwy for ; Tue, 28 Aug 2012 13:46:38 -0700 (PDT) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7C111E8099 for ; Tue, 28 Aug 2012 13:46:37 -0700 (PDT) Received: from mail-qc0-f182.google.com ([209.85.216.182]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUD0uLQ4mjCZdRoJprk5IZlU6t/ofh9Hs@postini.com; Tue, 28 Aug 2012 13:46:37 PDT Received: by qcsg15 with SMTP id g15so4611032qcs.13 for ; Tue, 28 Aug 2012 13:46:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=LSoPFVP0c7DmiRIRGXnF5xkEYHfyd+Mlv9jVFHVQW/c=; b=kGGrcfYMxBysAxXOAKehi+eMMrmvh8JEcewr4CUBwqQLMeNQwy+BKZga4+Wtpw17HF RUCkKKNBnlULP/qhauEKX1q0dSHlYFelnxDwVndbpAjQf6VafSNx7hZiTPoNso48Pk4p 9k7Df1/TIXG0DENa1FUEZZqZa+Qyk0tQL3buaBZZOhTKHt3EawNuS9/lLdhfB0GqI5lT 55mlFayEkqss//LTy8i5d5pjGW2lSRE+CjBsjES9DgdpPJakImBNorfiYTNPggObK54r tMhsD8WsXyXzIiZ+glG4/OTQH3PIfXKgyhFRiWBWTzCSsXCJ1Zqb5gmHkW19eloMlWSo /cbA== Received: by 10.224.115.208 with SMTP id j16mr10651336qaq.54.1346186796368; Tue, 28 Aug 2012 13:46:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.73 with HTTP; Tue, 28 Aug 2012 13:46:06 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943667A93F8@TK5EX14MBXC284.redmond.corp.microsoft.com> <503CD692.4020007@mitre.org> From: Brian Campbell Date: Tue, 28 Aug 2012 14:46:06 -0600 Message-ID: To: Breno de Medeiros Content-Type: multipart/alternative; boundary=20cf3074b1becc844b04c85989a8 X-Gm-Message-State: ALoCoQkSwpBBvSuMAZQKtAl3M4uAfRsvhUTBQa9odCEYKeJJ+sBvzgAljmBu0PCJOJTSfcC4tIiO Cc: Axel Nennker , Jim Schaad , Mike Jones , "jose@ietf.org" , John Bradley , Justin Richer 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 20:46:39 -0000 --20cf3074b1becc844b04c85989a8 Content-Type: text/plain; charset=ISO-8859-1 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 listjose@ietf.orghttps://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 > > --20cf3074b1becc844b04c85989a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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?=A0

I don't think it can be s= aid 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 do= cs. JWT is a layer above JOSE and, while there is a lot of overlap of peopl= e, is being developed in a completely different WG.

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

On Tue, Aug 2= 8, 2012 at 1:06 PM, Breno de Medeiros <breno@google.com> wrot= e:
I agree that this should be looked independe= ntly of oauth2.

Nonce is a generally used concept in cry= pto, though sometimes protocol designers have called for nonces with bad ou= tcomes because the difficulty of implementing nonce-checking was disregarde= d. 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 c= oncern ourselves with timestamps when considering nonces.



=
On Tue, Aug 28, 2012 at 8:09 AM, John Bradle= y <ve7jtb@ve7jtb.com> wrote:
In OAuth= 2 state gets overloaded with a bunch of things from preventing XSRF to pro= viding 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. = =A0

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. =A0 There are= cases where adding entropy to the header will be a security benefit. =A0I = would like to have a standard claim for doing that.
If people wan= t to call it something else that is fine, but it is a nonce by definition.<= /div>
If used it should be a random or pseudo random value that is time vari= ant with sufficient granularity to ensure a nonce is used only once.
<= div>
John B.

On 2012-08-28, at 10:32 AM, Justin Richer <jricher@mitre.org> wrote:
<= br>
=20 =20 =20
On 08/25/2012 03:37 AM, Axel Nennker wrote:
=20 To clarify: What is the base specification that Jim mentioned?
Is it: http://tools.ietf.org/html/draft-ietf-oauth-j= son-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.

=A0-- Justin

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

Axel

2012/8/25 Mike Jones <= ;Michael.J= ones@microsoft.com>
I'll note for discussion purposes that a nonce and a timestam= p are not the same thing (although sometimes they are used to achieve similar/related goals). =A0A nonce tends to be an opaque value that must be preserved across the communication. =A0Whereas 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. =A0This 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? =A0That would be my personal recommendation.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 B= est wishes,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -= - 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. =A0If 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: =A06 yes, 0 no, 1 discuss


_______________________________________________
jose mailing list
jose@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/jose



_______________________________________________
jose mailing list
jose@ietf.org
ht=
tps://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
ht= tps://www.ietf.org/mailman/listinfo/jose




--
--Breno
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--20cf3074b1becc844b04c85989a8--