Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC60E1B3950 for ; Wed, 4 Nov 2015 20:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2ku77P_ldyV for ; Wed, 4 Nov 2015 20:58:31 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1DB1B3943 for ; Wed, 4 Nov 2015 20:58:26 -0800 (PST) Received: by pabfh17 with SMTP id fh17so75269705pab.0 for ; Wed, 04 Nov 2015 20:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb_com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HsDpw8fbFTEPyTfzuNph2A9lvXXMvQoiheBJCEumfF8=; b=rg53J7H3Ix+R05ZvtJvUUO4BSphJLPIEbebkUgHJCMGlIBEqrs+W18Cf8htjKAdFSl DqIzfHHtJ4v5THqopOSlTmMpXM+z7S74n46eInqOlVfRlCbYCj6b/l6k58dMB09r6zrH 3JrTtDss/2nbX3eQrt2x1Lt6wrkMgQY5/YgxUiM4PWniDI4U22d9iN3AcxswEi9mJtOR wtpSrob3hQ1RQAsaACKwy7L134Ji46Q2t/4RNIUiPdc2mCsmhEBvqh6kaZLJ3EvVU3qm BW8USjkN4+l1d9qH2E93VpffJulyoymluc/TSDDuYzkBvWtQFLQhDBlTOwf2AjECj/dL UJow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HsDpw8fbFTEPyTfzuNph2A9lvXXMvQoiheBJCEumfF8=; b=U8cLYCvf6uchT/aI50wv1d/FE7GrsPVpph6ke4trSMnDz3PaUiqjwXeDly6yledM16 zBi9p5MDQgwBjwVBIMCdA2iU5MEUNIe6iQGOa4SY1vfYTBEA5fYb+4puMbgHKYoZABA2 6w7EdkE+RD27X/x1L5iDu1PxrEu90xtGbA4vqmp3Ry+7FaqvJU2yGnGHQYEfaOqkM6rq kWYIF4RkosBj5j6+EbiteZO+XKenCTp1B0cfqSJK7b5Sub6KxJZYVoDZRlpI2a8DQqCx pnbi4qEU2byvtLRYiMwFKz1bW+jNfae6wih2TNptNsTm68I8txYcPRA897Zz5jw00i1+ 1dmg== X-Gm-Message-State: ALoCoQlyCNb6Ym/tf8feo2afx3GazsLFL+qQjl6hgu7fVcrRpSDloXV4QfOyxKDjzcRF+ezsu96H X-Received: by 10.68.229.39 with SMTP id sn7mr6958940pbc.164.1446699506081; Wed, 04 Nov 2015 20:58:26 -0800 (PST) Received: from t20010c40000030089044b9d401462547.v6.meeting.ietf94.jp (t20010c40000030089044b9d401462547.v6.meeting.ietf94.jp. [2001:c40:0:3008:9044:b9d4:146:2547]) by smtp.gmail.com with ESMTPSA id zk3sm5117989pbb.41.2015.11.04.20.58.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 20:58:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Thu, 5 Nov 2015 13:58:23 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com> References: <563AA216.5010109@gmx.net> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:58:40 -0000 Good to know. So the AS needs to expose a public key for the TPM to = use for encryption. I am guessing you are not using a encrypted JWK = for that. What is the format the TPM produces the wrapped key in? John B. > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin = wrote: >=20 > I can say on all windows based devices (pc, xbox, phone, etc) with = only TPM 1.1 this will be the approach so it will be commonly used=20 >=20 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Wednesday, November 4, 2015 8:52 PM > To: Anthony Nadalin > Cc: Justin Richer ; > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs = spec addressing final shepherd comment >=20 > OK, no good reason unless the client is using a HSM that can do HMAC = and can export a symmetric key wrapped in a asymmetric key provided by = the AS. >=20 > We don=E2=80=99t currently cover that use case of sending a wrapped = symmetric key to the AS in POP key distribution. =20 > I don=E2=80=99t know how common that is going to be, but it is worth = thinking about defining. >=20 > John B. >=20 >> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin = wrote: >>=20 >> Not sure why you think its weaker as it would be a wrapped key that=20= >> the hardware produces >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >> Sent: Wednesday, November 4, 2015 8:43 PM >> To: Justin Richer >> Cc: >> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs=20 >> spec addressing final shepherd comment >>=20 >> In the asymmetric case the use of a HSM or secure element is the = argument for the client selecting the public key. In those cases the = client is doing the key gen in hardware so one hopes it is OK. In the = symetric case the client generating the key is weaker (as in I can=E2=80=99= t think of any really good reason). >>=20 >>=20 >>> On Nov 5, 2015, at 1:35 PM, Justin Richer wrote: >>>=20 >>> I=E2=80=99d argue that it=E2=80=99s best practice, and in line with = other parts of OAuth, if we assume the server generates it in the normal = case (issuer -> presenter). Client generated token keys should be an = exception, especially in the asymmetric case. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Nov 5, 2015, at 1:32 PM, John Bradley wrote: >>>>=20 >>>> Agreed the only real difference is the quality of the key. If the = server generates it, then it knows that the client is not using the = fixed hex value of DEADBEEF for everything. >>>>=20 >>>> John B. >>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig = wrote: >>>>>=20 >>>>> I agree that the effect is the same. =46rom a security point of = view=20 >>>>> there is only an impact if one of the two parties is in a better=20= >>>>> position to generate random numbers, which is the basis for=20 >>>>> generating a high entropy symmetric key. >>>>>=20 >>>>> On 11/04/2015 11:51 PM, Mike Jones wrote: >>>>>> Thanks for the detailed read, Brian. You=E2=80=99re right that = in the=20 >>>>>> symmetric case, either the issuer or the presenter can create the=20= >>>>>> symmetric PoP key and share it with the other party, since the = effect is equivalent. >>>>>> I suspect that both the key distribution draft and this draft=20 >>>>>> should be updated with a sentence or two saying that either=20 >>>>>> approach can be taken. Do others concur? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> *From:*Brian Campbell [mailto:bcampbell@pingidentity.com] >>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM >>>>>> *To:* Mike Jones >>>>>> *Cc:* Kepeng Li; oauth@ietf.org >>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for=20= >>>>>> JWTs spec addressing final shepherd comment >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> +1 for the diagrams making the document more understandable. >>>>>>=20 >>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric=20= >>>>>> keys shows the Presenter sending the key to the Issuer. It's=20 >>>>>> possible, however, for the key to be sent the other way. = Presenter=20 >>>>>> sending it to the Issuer is probably preferred for asymmetric,=20 >>>>>> especially if the client can secure the private keys in hardware. >>>>>> But I don't know if one way or the other is clearly better for=20 >>>>>> symmetric case and PoP key distribution currently has it the = other=20 >>>>>> way = . >>>>>> Should the intro text somehow mention the possibility that the=20 >>>>>> Issuer could create the key and send it to the Presenter? >>>>>>=20 >>>>>> I know it's only the introduction but it was just something that=20= >>>>>> jumped out at me. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones=20 >>>>>> > wrote: >>>>>>=20 >>>>>> Thanks for suggesting the diagrams, Kepeng. They make the = document=20 >>>>>> more understandable. >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> = ------------------------------------------------------------------ >>>>>> - >>>>>> ----- >>>>>>=20 >>>>>> *From: *Kepeng Li >>>>>> *Sent: *=E2=80=8E11/=E2=80=8E5/=E2=80=8E2015 12:57 AM >>>>>> *To: *Mike Jones ; >>>>>> oauth@ietf.org >>>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec=20 >>>>>> addressing final shepherd comment >>>>>>=20 >>>>>> Thank you Mike. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The diagrams look good to me. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Kind Regards >>>>>>=20 >>>>>> Kepeng >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA**: *Mike Jones = >>>>> > >>>>>> *=E6=97=A5=E6=9C=9F**: *Thursday, 5 November, 2015 12:32 am >>>>>> *=E8=87=B3**: *"oauth@ietf.org " = >>>>> > >>>>>> *=E6=8A=84=E9=80=81**: *Li Kepeng >>>>> > >>>>>> *=E4=B8=BB=E9=A2=98**: *Proof-of-Possession Key Semantics for = JWTs spec addressing=20 >>>>>> final shepherd comment >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses = the=20 >>>>>> remaining document shepherd comment =E2=80=93 adding use case = diagrams to=20 >>>>>> the introduction. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The updated specification is available at: >>>>>>=20 >>>>>> =C2=B7 = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2ftools.ie= tf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-06&data=3D01%7c01%7ct= onynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141= af91ab2d7cd011db47%7c1&sdata=3D6hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLt= Cw%3d >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> An HTML formatted version is also available at: >>>>>>=20 >>>>>> =C2=B7 =20 >>>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fs >>>>>> e=20 >>>>>> = lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-06.ht >>>>>> m >>>>>> = l&data=3D01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d >>>>>> 2=20 >>>>>> = e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DEQd4rUcuyqdS >>>>>> P gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> P.S. This note was also posted at=20 >>>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fself-iss= ued.info%2f%3fp%3d1471&data=3D01%7c01%7ctonynad%40microsoft.com%7c94566700= 75d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DTM= fX1tG5qucl%2be2KVpyMBuj72ZQ%2f%2bEKGoTyJyf%2bfJi4%3d and as @selfissued = . >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org =20 >>>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw >>>>>> w=20 >>>>>> = w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m >>>>>> i >>>>>> = crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9 >>>>>> 1=20 >>>>>> = ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK >>>>>> J >>>>>> s%3d >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fw >>>>>> w=20 >>>>>> = w.ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40m >>>>>> i >>>>>> = crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9 >>>>>> 1=20 >>>>>> = ab2d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK >>>>>> J >>>>>> s%3d >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww >>>>> w=20 >>>>> = .ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40mic >>>>> r >>>>> = osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab >>>>> 2=20 >>>>> = d7cd011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3 >>>>> d >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >>>> = ietf.org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40micro >>>> s=20 >>>> = oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7 >>>> c d011db47%7c1&sdata=3DND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d= >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i >> = etf.org%2fmailman%2flistinfo%2foauth%0a&data=3D01%7c01%7ctonynad%40micro >> = soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7c >> d011db47%7c1&sdata=3DBLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d >=20