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

John Bradley <ve7jtb@ve7jtb.com> Wed, 02 April 2014 13:44 UTC

Return-Path: <ve7jtb@ve7jtb.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 60B581A0209 for <oauth@ietfa.amsl.com>; Wed, 2 Apr 2014 06:44:54 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZKRL6WLQ0Pbu for <oauth@ietfa.amsl.com>; Wed, 2 Apr 2014 06:44:49 -0700 (PDT)
Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) by ietfa.amsl.com (Postfix) with ESMTP id 952AB1A01D9 for <oauth@ietf.org>; Wed, 2 Apr 2014 06:44:49 -0700 (PDT)
Received: by mail-qg0-f42.google.com with SMTP id q107so214534qgd.1 for <oauth@ietf.org>; Wed, 02 Apr 2014 06:44:45 -0700 (PDT)
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=B8oxte+Qc7zBuCtdAE+ZOkdiWx94FmSXjtyAJyYWKkk=; b=AlQ9mstfbFpCj7Ffym/DVPI/f/fHPrhJaEy+fP51uhbXjWnQdYoxdeL/ctQ7vtwR9A GaDHPtHbRlEbQIsiScnTwKTvzF2uUsJ5TigLsBg3pEMkYJJ974Vw4pEOrL92efrPfvwd G3q0VrGzFpA77CSDk9tc8BsKOrl3hjcoaNH1625a588/D7bq0jO3bXO0bHbIR2E8lIWO P+hIJRpvwQU8bQ5A5U0Z2j4YbNi5pCb7pFoQvGT21L4QuIbd8ErgodbzNAXYbUcfW8G5 fel3sssd9qwTsAn7cTmsym3xOrTyy23O4YrAW+g88GR/s1z7idiPCrLR6HdSDJqO9lOd Xhqw==
X-Gm-Message-State: ALoCoQm6KK4e6y3U9SEpNurmch08QvkKsnatcrD++haPtPJ0Y6SrVbZRYnTX2vGvV1FvIi5Ps0em
X-Received: by 10.224.49.67 with SMTP id u3mr628385qaf.63.1396446285408; Wed, 02 Apr 2014 06:44:45 -0700 (PDT)
Received: from [107.16.249.57] ([107.16.249.57]) by mx.google.com with ESMTPSA id u59sm2675880qga.8.2014.04.02.06.44.44 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 06:44:44 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115446A5608@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 02 Apr 2014 09:44:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0AEB91A8-B99B-4263-AB26-353F3ED27288@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B16804296739439A132083@TK5EX14MBXC286.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E115446A5608@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LDBT-u0-e8ckK8mtsLyDWzXuf-0
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: Wed, 02 Apr 2014 13:44:54 -0000

Thanks for the feedback.

inline
On Apr 2, 2014, at 1:50 AM, Manger, James <James.H.Manger@team.telstra.com> wrote:

>> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00
> 
> 
> A new registry for "cnf" members is a bit strange. A JWT Claim Set has so far been a flat structure, with metadata such expiry date "exp" alongside claims such as "given_name". This spec starts introducing structure by wrapping members in a "cnf" (confirmation) object. It is not clear to me which new things would go in "cnf" versus going in to the top-level of the JWT claim set. Both locations have a "MUST ignore" policy for unrecognized members.

This is the first draft so this needs to be fleshed out.  The idea is to have a single object that contains what in SAML would be the subject confirmation information.   I expect hat the protocols using this are going to determine what claims need to go in cnf.   

As an example for bearer tokens there might be an expirey time for presentment that is separate from the tokens lifetime as represented by "exp" at the top level.
This may not be a great example as people in general don't understand the difference between the two exp in SAML:)   

But in general cnf contains claims that are required to confirm that the presenter is the subject/issuer or a designated agent.

> 
> 
>   "(In some applications, the subject identifier will be relative
>   to the issuer identified by the "iss" (issuer) claim.)"
> 
> This isn’t very helpful as it gives no hint about when this is or isn’t the case. I guess this is just rewording a flaw from JWT.

This is one thing we have been wrangling over the wording of.

In the simple case where there is a "sub" then the key represents the proof key of the presenter or a authorized agent on there behalf.

There are some slippery bits even in that as it is the recipient that is trusting the issuer to put in the correct cnf information. Especially in cases where there may be multiple hops the key may be that of a RS that the user has no direct trust relationship with.

In the case where there is no subject, I tend to think of the JWT as having a implicit subject that is the issuer as that is really the only thing the claims could be about in the absence of a explicit subject.
A JWT without a subject could have a claim about a user that is logged into me but the me is the issuer.

So as in the case of there being no explicit subject the cnf is of the iss or a agent it has designated.

In principal if a intermediary receives the token and sends it to a STS like service the resulting JWT would then have the STS as the iss and the original iss as the sub.  Though that is outside of this spec.

Trying to come up with a simple explanation without dragging a bunch of other stuff in to the spec is not easy.

Perhaps something more like the cnf must evaluate to true for the presenter of the JWT otherwise the token is not being presented by a party authorized by the issuer, given that the recipient's primary trust relationship is with the issuer.

Trying to say who the presenter is may just be too confusing at this level.

Thoughts and wording input appreciated.


> 
> 
> Could the JWE example please include a "kid"? The recipient needs to know which key to use to decrypt the message. JWS says we SHOULD do this [JWS §6 2nd paragraph]. [P.S. Weren’t we going to include "kid" is almost all the examples in JWE?]

Yes it should include a "kid"
> 
> You may as well drop the "cty":"jwk+json" member as this is implied by the JOSE message being the value of a "jwk" member.
> 
It may be useful to libraries processing the JWE.

> 
> OpenID Connect has already defined a "sub_jwk" field that performs a similar role to "cnf":{"jwk"}.
> [http://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedResponse]

As you have pointed out connect self Issued needs an errata to address a problem anyway.

They are similar though the self issued case is more like a JWT that would be used as a proof mechanism rather than as a pop token itself.

Perhaps there is a case where the iss is using it's signing key for signing the token and via tls channel binding for presentment as an example. 

The connect case doesn't require a presentment proof so is a bit different.    

I take your point and will think about it a bit more.


> 
> 
> Perhaps the biggest security consideration is missing: "cnf" may be ignored. A recipient that doesn't understanding "cnf" is likely to accept a JWT as a bearer token without doing any proof-of-possession.
> 

I think the protocol using the JWT would likely be where the requirement would be enforced along with the presentment mechanism.

John B.

> --
> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth