Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Justin Richer <jricher@mit.edu> Thu, 05 November 2015 04:48 UTC

Return-Path: <jricher@mit.edu>
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 81B561B38EB for <oauth@ietfa.amsl.com>; Wed, 4 Nov 2015 20:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AtsP8als3Tuf for <oauth@ietfa.amsl.com>; Wed, 4 Nov 2015 20:48:07 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193391B3643 for <oauth@ietf.org>; Wed, 4 Nov 2015 20:48:06 -0800 (PST)
X-AuditID: 12074425-f79816d000004571-fa-563adf85d8a8
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 42.B3.17777.58FDA365; Wed, 4 Nov 2015 23:48:05 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tA54m4M7018967; Wed, 4 Nov 2015 23:48:05 -0500
Received: from dhcp-29-147.meeting.ietf94.jp (dhcp-29-147.meeting.ietf94.jp [133.93.29.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA54m045012067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Nov 2015 23:48:03 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <BN3PR0301MB12343B9AA4D6842E09D6A5BFA6290@BN3PR0301MB1234.namprd03.prod.outlook.com>
Date: Thu, 5 Nov 2015 13:47:59 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <E6E4E38C-B1A8-4148-BB78-D1595011E636@mit.edu>
References: <BY2PR03MB442F6667C49F8CF260D504DF52A0@BY2PR03MB442.namprd03.prod.outlook.com> <D2605993.2210B%kepeng.lkp@alibaba-inc.com> <BY2PR03MB4423CADD0E9897848961B99F52A0@BY2PR03MB442.namprd03.prod.outlook.com> <CA+k3eCRW=ggajMeL1z2cvLDkou9XsLMupicH-5HyDkadj0_o_g@mail.gmail.com> <BY2PR03MB44262EA4616E08287A91DB1F52A0@BY2PR03MB442.namprd03.prod.outlook.com> <563AA216.5010109@gmx.net> <A926F104-1624-4F32-9246-662594E66F5E@ve7jtb.com> <89A6E4DE-263B-4DB4-8882-54FA7103C721@mit.edu> <82079E8A-2AC8-4A42-9AF7-77FF2A3CAFC2@ve7jtb.com> <BN3PR0301MB12343B9AA4D6842E09D6A5BFA6290@BN3PR0301MB1234.namprd03.prod.outlook.com>
To: Anthony Nadalin <tonynad@microsoft.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0W29bxVmcPK/tsXJt6/YLDbN3cZo sfruXzYHZo8lS34yebTu+Mvucfv2RpYA5igum5TUnMyy1CJ9uwSujHdfdjIVzAuoWHu6gaWB 8YpLFyMnh4SAicSOMw9ZIGwxiQv31rN1MXJxCAksZpJYdfgGO4SzgVHi+6GjUJkbTBI3m8+x gbQwC6hL/Jl3iRnE5hXQk3h16zIriC0skCnx+nAPWJxNQFVi+poWJhCbUyBR4srPZ2C9LAIq Ei+WHWWFmOMpsefZBUYIW1ti2cLXQL0cQDOtJHZPcIfY+4ZF4tHR5WC9IkA1J96vZIY4W1Zi 9+9HTBMYBWchOWkWkpNmIRm7gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6FXm5miV5qSukm RnBYu6juYJxwSOkQowAHoxIPr0G1VZgQa2JZcWXuIUZJDiYlUV6rc0AhvqT8lMqMxOKM+KLS nNTiQ4wSHMxKIrwFM4FyvCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIcHEoS vL73gBoFi1LTUyvSMnNKENJMHJwgw3mAht+9CzK8uCAxtzgzHSJ/ilFRSpz3JEhCACSRUZoH 1wtKO62xspNfMYoDvSLMmwWyggeYsuC6XwENZgIazNRqATK4JBEhJdXAaJ8nsFT4S2312qJZ DZ+qErfLbzr8YrLmrlu9X+94Pp71z/tH8ufSsMbY3dk/t4q8+qh96+KffTtObayR0jGacvNf UWHX3tgTehItsR+Oqm2JTl8mwdl8R/lshn3lJtdb77Ly1zRXH9EMmu/A1ZQd+d7AqudIbY5J xX72+8HBeqec9+x7kXhXWImlOCPRUIu5qDgRAJimuw8WAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/qVUZ2NJbnrwLS2_3QE4NM0MHUFo>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2015 04:48:11 -0000

That’s only if you’re using good hardware to produce a key. We can’t assume that’s the only kind of client that will exist, and software generation is likely to be much more common for a while yet.

Perhaps what we really need is strong guidance on when to use which approach. “If you client has a strong random generator function then you can make your own key, but otherwise let the server do it for you."

 — Justin

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that the hardware produces 
> 
> -----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 <jricher@mit.edu>
> Cc: <oauth@ietf.org> <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment
> 
> 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’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer <jricher@mit.edu> wrote:
>> 
>> I’d argue that it’s 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.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>> 
>>> 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.
>>> 
>>> John B.
>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>>> 
>>>> I agree that the effect is the same. From a security point of view 
>>>> there is only an impact if one of the two parties is in a better 
>>>> position to generate random numbers, which is the basis for 
>>>> generating a high entropy symmetric key.
>>>> 
>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>>> symmetric case, either the issuer or the presenter can create the 
>>>>> 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 
>>>>> should be updated with a sentence or two saying that either 
>>>>> approach can be taken.  Do others concur?
>>>>> 
>>>>> 
>>>>> 
>>>>>                                                         -- Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> *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 
>>>>> JWTs spec addressing final shepherd comment
>>>>> 
>>>>> 
>>>>> 
>>>>> +1 for the diagrams making the document more understandable.
>>>>> 
>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>>> possible, however, for the key to be sent the other way. Presenter 
>>>>> sending it to the Issuer is probably preferred for asymmetric, 
>>>>> 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 
>>>>> symmetric case and PoP key distribution currently has it the other 
>>>>> way <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-distribution-02%23section-4.2&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgZEoqQiaUk9VdYpSQRvUeVVOQgIUg3UmAr18oQ7GtI%3d>.
>>>>> Should the intro text somehow mention the possibility that the 
>>>>> Issuer could create the key and send it to the Presenter?
>>>>> 
>>>>> I know it's only the introduction but it was just something that 
>>>>> jumped out at me.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
>>>>> <Michael.Jones@microsoft.com <mailto:Michael.Jones@microsoft.com>> wrote:
>>>>> 
>>>>> Thanks for suggesting the diagrams, Kepeng. They make the document 
>>>>> more understandable.
>>>>> 
>>>>> -- Mike
>>>>> 
>>>>> -------------------------------------------------------------------
>>>>> -----
>>>>> 
>>>>> *From: *Kepeng Li <mailto:kepeng.lkp@alibaba-inc.com>
>>>>> *Sent: *‎11/‎5/‎2015 12:57 AM
>>>>> *To: *Mike Jones <mailto:Michael.Jones@microsoft.com>; 
>>>>> oauth@ietf.org <mailto:oauth@ietf.org>
>>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec 
>>>>> addressing final shepherd comment
>>>>> 
>>>>> Thank you Mike.
>>>>> 
>>>>> 
>>>>> 
>>>>> The diagrams look good to me.
>>>>> 
>>>>> 
>>>>> 
>>>>> Kind Regards
>>>>> 
>>>>> Kepeng
>>>>> 
>>>>> 
>>>>> 
>>>>> *发件人**: *Mike Jones <Michael.Jones@microsoft.com 
>>>>> <mailto:Michael.Jones@microsoft.com>>
>>>>> *日期**: *Thursday, 5 November, 2015 12:32 am
>>>>> *至**: *"oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org 
>>>>> <mailto:oauth@ietf.org>>
>>>>> *抄送**: *Li Kepeng <kepeng.lkp@alibaba-inc.com 
>>>>> <mailto:kepeng.lkp@alibaba-inc.com>>
>>>>> *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing 
>>>>> final shepherd comment
>>>>> 
>>>>> 
>>>>> 
>>>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the 
>>>>> remaining document shepherd comment – adding use case diagrams to 
>>>>> the introduction.
>>>>> 
>>>>> 
>>>>> 
>>>>> The updated specification is available at:
>>>>> 
>>>>> ·        https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-proof-of-possession-06&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6hE6dOO0I1%2ffF005rVknyOFHuB18gdpZg9dftExLtCw%3d
>>>>> 
>>>>> 
>>>>> 
>>>>> An HTML formatted version is also available at:
>>>>> 
>>>>> ·       
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fse
>>>>> lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-06.htm
>>>>> l&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2
>>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EQd4rUcuyqdSP
>>>>> gmibtcfjMpJm6RWWwCZC85%2bCboEs54%3d
>>>>> 
>>>>> 
>>>>> 
>>>>>                                                         -- Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> P.S.  This note was also posted at 
>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2f%3fp%3d1471&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TMfX1tG5qucl%2be2KVpyMBuj72ZQ%2f%2bEKGoTyJyf%2bfJi4%3d and as @selfissued <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LfFAjchzCTh0x%2fY9hr0W%2fSohPGgb0JVjL%2f2Az%2f12BCg%3d>.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> 
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fww
>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mi
>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91
>>>>> ab2d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJ
>>>>> s%3d
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fww
>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mi
>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91
>>>>> ab2d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJ
>>>>> s%3d
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww
>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr
>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2
>>>> d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros
>>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7c
>>> d011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth%0a&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d