Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

Chuck Mortimore <cmortimore@salesforce.com> Sun, 13 April 2014 16:31 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 D5C711A01DA for <oauth@ietfa.amsl.com>; Sun, 13 Apr 2014 09:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 DqV7D5P8Q0J0 for <oauth@ietfa.amsl.com>; Sun, 13 Apr 2014 09:31:44 -0700 (PDT)
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id 67B581A01DC for <oauth@ietf.org>; Sun, 13 Apr 2014 09:31:44 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id va2so8220170obc.0 for <oauth@ietf.org>; Sun, 13 Apr 2014 09:31:42 -0700 (PDT)
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=GVPQENbfZVwwPxw1CxrCcT2Hd6nbdTQ+aH5vWorPMOg=; b=ZJL5Ypc7JCQTSn7w7W21XqbHrwWPXs54lOskohazFCKP51kMI/XWm4/Ei7DXppbeA8 09UQFTBuozRqUGMjbmvzkJD0iprGCc/Uv3XagreGnJlWWtqMqAkn0y/MBnvbL5z+0aMT wDy+irrOK75Ef3pG2DUyaJXllmoGhpmB5GZIIwfvVm46tt6x6bxWcj1D3xFU7yBxwZ+/ eqhRIJnHaLZ+uExwg6bN1J1hmESWhchE7dhs4JaL8UPo+EntJ5Th9EzjFOx2caqDpQ5y ExV1FZLxHa/QGcgQYJv8arfc/3sRbyS44WP4/3RjX5Hu5OS40kBlNrl606lvmZgWtPnQ yaWg==
X-Gm-Message-State: ALoCoQkIFx4dKHHCI96euoFQ0YD6gpehQFaunJ3TNFcl/6ZU64FRVt31P338XaBinCJ0iJf4LeZn
MIME-Version: 1.0
X-Received: by 10.60.160.173 with SMTP id xl13mr30574936oeb.19.1397406702084; Sun, 13 Apr 2014 09:31:42 -0700 (PDT)
Received: by 10.76.75.169 with HTTP; Sun, 13 Apr 2014 09:31:41 -0700 (PDT)
In-Reply-To: <C782E37A-A38D-4C12-8029-B5934ADA3977@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B16804296739439A132083@TK5EX14MBXC286.redmond.corp.microsoft.com> <CA+wnMn_LBojNz+LCTTQN62P_U7Rag0rot715c7XCOcXAQJmEhA@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439A155FFB@TK5EX14MBXC286.redmond.corp.microsoft.com> <CA+wnMn-Dto7ySgNgMu5rkqyzfok1BWdS7WxB18ep+Uv0sFRsuw@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439A15609B@TK5EX14MBXC286.redmond.corp.microsoft.com> <C782E37A-A38D-4C12-8029-B5934ADA3977@ve7jtb.com>
Date: Sun, 13 Apr 2014 09:31:41 -0700
Message-ID: <CA+wnMn_LyO4wmhfuPYnNO87sq8c-p4zgpKbNqUnEYhJzvCpmhg@mail.gmail.com>
From: Chuck Mortimore <cmortimore@salesforce.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=089e011764e915b50404f6ef1ad7
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yR4KUEidNLPUHr9BFWzbTheo6e8
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
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: <http://www.ietf.org/mail-archive/web/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: Sun, 13 Apr 2014 16:31:49 -0000

Yes - sounds about what I'm looking at

For the scenario, we'd have a client talking to our authorization server
that is also paired with it's own cloud backend.   The cloud would have a
certificate pre-reigstered with our authorization server, and the client
would dynamically generate it's own public/private key.    Both would be
able to prove possession using their own keys without sharing.    So to
answer mike's data structure question, it would looks something like this

1) Client requests id token and in the authorization request it passes in
its newly minted public key ( or perhaps a thumbprint but not covering that
here)

2) Authorization server authorizes, and mints new id token as jwk set
containing both the dynamically generated client key and also the cert for
its server:

{
     "iss": "https://login.salesforce.com",
     "sub": "
https://login.salesforce.com/id/00D30000001bZxaEAE/00530000009UVC0AAO"
     "aud":
"3MVG99OxTyEMCQ3gXuX31lysX3RQP4.Vj3EVzlMsVbxFvUe7VjZ0WcjWvGlAU7BPJFZBSyBGPiGyHhojZ2BE3",
     "exp": 1397352138,
     "iat": 1397352018,
     "cnf":
  {
"keys":[
{
"kty": "RSA",
"n": "AKPBc9I142dEc-Srdk5sz9MVaJH_k....",
"e": "AQAB",
"alg": "RS256"
},
{
"x5c":["MIIDQjCCAi...."]
}
]
}
}


The id token can then be presented to something like our oauth token
endpoint as an assertion by either the client application such as a mobile
app, or the server infrastructure it's paired with.   The client's key is
client specific.   The server's key is global for the application.  No need
to share between them, and the capabilities of the grant could vary.

Proof would simply be constructing a JWT that signs the id token with the
required key:
outerheader.base64url(innerheader.body.innersignature).outersignature

-cmort



On Sun, Apr 13, 2014 at 8:34 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> I think Chuck is largely referring to the scenario that Connect supports
> for issuing id_tokens for 3rd parties but where the 3rd party also wants a
> access token to access the API.
>
> This is similar to the Google Play / NAAPS use case, but with access
> tokens using PoP back to the 1st party RS.
>
> Now using bearer tokens the native app can just pass the AT to a backend
> server hand have it make calls to the RS.  The AS is no wiser to the
> activity.
> However PoP is designed to stop this sort of thing.
>
> As I think Chuck intimated, you could share the private key between the
> app and the backend, but giving your servers private key to a app seems
> like a good way to loose it.
>
> The alternatives are:
> 1 share keys (bad)
> 2 put multiple proof keys in the token (needs the keys to be pre
> registered and ads complexity for symmetric keys.
> 3 Give client an assertion that can be used by the related backend to get
> it's own AT, allowing the clients to have different client_id and proof
> keys. (builds on Connect id_token used in jwt assertion flow)
>
> John B.
>
> On Apr 13, 2014, at 1:17 AM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
> Can you sketch out what data structures you'd ideally use for your
> scenario and what the elements mean?
>
> *From:* Chuck Mortimore [mailto:cmortimore@salesforce.com<cmortimore@salesforce.com>
> ]
> *Sent:* Saturday, April 12, 2014 8:39 PM
> *To:* Mike Jones
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web
> Tokens (JWTs)
>
> Not sure it it's common yet.   The scenario I'm exploring is a client that
> is paired with a server.     For example, a mobile app that's an OpenID
> Connect client that is sharing it's ID Token with the server.   Both the
> client and server want to be able to prove possession without sharing a
> private key.
>
> -cmort
>
>
> On Sat, Apr 12, 2014 at 8:32 PM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
> Is having multiple confirmation keys a common case?  I'd rather we "make
> simple things simple" than build the most general solution possible.  If an
> application really needs multiple confirmation keys, it can always defined
> a "jwks" element and the handling rules for it, and go for it...
>
>                                                             -- Mike
>
> *From:* Chuck Mortimore [mailto:cmortimore@salesforce.com]
> *Sent:* Saturday, April 12, 2014 6:12 PM
> *To:* Mike Jones
>
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web
> Tokens (JWTs)
>
> Good start here Mike!
>
> One quick question - I see the "cnf" member is defined as a JWK.  Why not
> a JWK Set?    I could see use-cases for binding in multiple keys.
>
> -cmort
>
>
>
>
> On Tue, Apr 1, 2014 at 8:36 PM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
> I've written a concise Internet-Draft on proof-of-possession for JWTs with
> John Bradley and Hannes Tschofenig.  Quoting from the abstract:
>
> *This specification defines how to express a declaration in a JSON Web
> Token (JWT) that the presenter of the JWT possesses a particular key and
> that the recipient can cryptographically confirm proof-of-possession of the
> key by the presenter. This property is also sometimes described as the
> presenter being a holder-of-key.*
>
> This specification intentionally does not specify the means of
> communicating the proof-of-possession JWT, nor the messages used to
> exercise the proof key, as these are necessarily application-specific.
> Rather, this specification defines a proof-of-possession JWT data structure
> to be used by other specifications that do define those things.
>
> The specification is available at:
>
> ·
> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00
>
> An HTML formatted version is available at:
>
> ·
> http://self-issued.info/docs/draft-jones-oauth-proof-of-possession-00.html
>
>                                                             -- Mike
>
> P.S.  This note was also posted at http://self-issued.info/?p=1210 and as
> @selfissued.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>