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

Chuck Mortimore <cmortimore@salesforce.com> Thu, 05 November 2015 20:07 UTC

Return-Path: <cmortimore@salesforce.com>
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 B25AC1B3617 for <oauth@ietfa.amsl.com>; Thu, 5 Nov 2015 12:07:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.693
X-Spam-Level:
X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URI_NO_WWW_INFO_CGI=2.071] autolearn=no
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 b4gWDXlEwz-w for <oauth@ietfa.amsl.com>; Thu, 5 Nov 2015 12:07:20 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 674011B360D for <oauth@ietf.org>; Thu, 5 Nov 2015 12:07:20 -0800 (PST)
Received: by igbhv6 with SMTP id hv6so19362400igb.0 for <oauth@ietf.org>; Thu, 05 Nov 2015 12:07:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jW+ceuq5IkbQ8nUj/C4tUsxF1ZCEVxjRY3z/iLinu2g=; b=EbyQsXsVyoQxTQhGDCHSOnyyuDBEnZAa74yOJwk1rGituaNRTUiSUC/eEUnk4+Ne0P FKTM56A2VONKtOeb37c0MaA7UB3NvlOW1TAvt+k6IxQGbxzq53aa5RWu2hMp635w+4gC QqgE3aeqAQ35+n4sqcPJM4QHKF0+m+y4S8t2E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jW+ceuq5IkbQ8nUj/C4tUsxF1ZCEVxjRY3z/iLinu2g=; b=ipwfXTwi2v8n78+yw8PDvBPOG29l7oev8yq1obm6zC8bPGuT0KUcBnzAHwDLs5q47Z zG194x5r+vpx7NJ/BApgp/fGfO5fQFaMRAHal28SqCB47C/9eHmsAQkC547v6aIztqPg 67Tk9ho/a66gKGzJhYvJids+fSSPYxGMx61SvXcjBF6cHVUQI5iAIpYhHmoBPnQ3MU9d 7jKtyYbwFa3/BfSCuIHhpgTvhgfrWDYw8SMbap0vC/WY6OUzYKP43cyo3Yz7PFSpsneE SkK5ZnPCzTgtXArw6wvZjWDLDeoFjX6g30qfo9xaOjQ13gouCVQgaRrbRvLVGeD8BIGo Vutw==
X-Gm-Message-State: ALoCoQmr0OXo3MF6HDoHrMUc5+t1i/XV92GINaf0jVpvEdtEKBwH03xaZ2CSwphmT2TciECeT6kD
MIME-Version: 1.0
X-Received: by 10.50.79.135 with SMTP id j7mr5164543igx.73.1446754039564; Thu, 05 Nov 2015 12:07:19 -0800 (PST)
Received: by 10.64.146.195 with HTTP; Thu, 5 Nov 2015 12:07:17 -0800 (PST)
In-Reply-To: <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com>
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> <9E23AF3A-F758-4CB4-B920-4E1E2F61BCF4@ve7jtb.com> <BN3PR0301MB1234DE4EC9D49CC56A62173CA6290@BN3PR0301MB1234.namprd03.prod.outlook.com> <4D05C317-FF58-4CDE-98BE-D4ED1E078526@ve7jtb.com>
Date: Thu, 5 Nov 2015 12:07:17 -0800
Message-ID: <CA+wnMn9sJqHmkO8gQk-aCsMDmkSV6RqJKwB7=3cSk5E7K=nGrw@mail.gmail.com>
From: Chuck Mortimore <cmortimore@salesforce.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=089e0122a7549b63b80523d0ac74
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/73GH02DcCS6CtBDtcXpsc699ZiI>
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 20:07:26 -0000

The spec is very clear for most cases, but I think it could use some
guidance on nested JWTs.    (Or perhaps I've got the approach wrong.)

Here's the use-case:
We have devices that are self-issuing keys.    Via token exchange, we're
going to except a self-signed JWT from the device that includes a "cnf"
claim of the key they generated.    Assuming the signature checks out on
that JWT, we'll then bind that key into a "cnf" claim in a new token that
we issue and sign with a tenant key.

When the device goes to use that token, the device would sign it,
constructing a nested JWT.  The outer signature is the proof of possession
of the device's private key.   The inner signature is our signature that
binds the public key used to validate the outer token.

Does this sound correct?   The processing order is a bit odd since you
first need to unpack and validate the inner token before you can validate
the outer token.   Is there some other way this is intended to work?

thanks

-cmort



On Wed, Nov 4, 2015 at 8:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> 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 <tonynad@microsoft.com>
> wrote:
> >
> > 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
> >
> > -----Original Message-----
> > From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> > Sent: Wednesday, November 4, 2015 8:52 PM
> > To: Anthony Nadalin <tonynad@microsoft.com>
> > Cc: Justin Richer <jricher@mit.edu>; <oauth@ietf.org> <oauth@ietf.org>
> > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec
> addressing final shepherd comment
> >
> > 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.
> >
> > We don’t currently cover that use case of sending a wrapped symmetric
> key to the AS in POP key distribution.
> > I don’t know how common that is going to be, but it is worth thinking
> about defining.
> >
> > John B.
> >
> >> 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%2fs
> >>>>>> e
> >>>>>> lf-issued.info%2fdocs%2fdraft-ietf-oauth-proof-of-possession-06.ht
> >>>>>> m
> >>>>>> l&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d
> >>>>>> 2
> >>>>>> e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EQd4rUcuyqdS
> >>>>>> P 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%2fw
> >>>>>> w
> >>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40m
> >>>>>> i
> >>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9
> >>>>>> 1
> >>>>>> ab2d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK
> >>>>>> J
> >>>>>> s%3d
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> OAuth mailing list
> >>>>>> OAuth@ietf.org
> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw
> >>>>>> w
> >>>>>> w.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40m
> >>>>>> i
> >>>>>> crosoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af9
> >>>>>> 1
> >>>>>> ab2d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQK
> >>>>>> J
> >>>>>> 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%40mic
> >>>>> r
> >>>>> osoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab
> >>>>> 2
> >>>>> d7cd011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3
> >>>>> d
> >>>>
> >>>> _______________________________________________
> >>>> 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%40micro
> >>>> s
> >>>> oft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7
> >>>> c d011db47%7c1&sdata=ND3ydaXOsPMsoRhE0Uyq0uznGy6MdYOLZQJHLhEQKJs%3d
> >>>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> >> etf.org%2fmailman%2flistinfo%2foauth%0a&data=01%7c01%7ctonynad%40micro
> >> soft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7c
> >> d011db47%7c1&sdata=BLqSuDjWLY72fGm0UrpLwxQVnamMelggJeOpYJESVFs%3d
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>