Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

Anthony Nadalin <tonynad@microsoft.com> Thu, 05 March 2015 18:11 UTC

Return-Path: <tonynad@microsoft.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 CCFDC1A6EF0 for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 10:11:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 JGQak-54BiA7 for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 10:11:06 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23531A6ED9 for <oauth@ietf.org>; Thu, 5 Mar 2015 10:11:05 -0800 (PST)
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1235.namprd03.prod.outlook.com (25.161.207.23) with Microsoft SMTP Server (TLS) id 15.1.99.14; Thu, 5 Mar 2015 18:11:03 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0099.004; Thu, 5 Mar 2015 18:11:03 +0000
From: Anthony Nadalin <tonynad@microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline
Thread-Index: AQHQVolBYKU2iEv0rEGFakA1XyRiFJ0M93/wgAACxYCAATVkgA==
Date: Thu, 5 Mar 2015 18:11:03 +0000
Message-ID: <BN3PR0301MB1234BCFA5E1BEAE1092CC519A61F0@BN3PR0301MB1234.namprd03.prod.outlook.com>
References: <54F71978.5090804@gmx.net> <BN3PR0301MB123410743EF24605A084B1D2A61E0@BN3PR0301MB1234.namprd03.prod.outlook.com> <4E1F6AAD24975D4BA5B1680429673943A2E78DFF@TK5EX14MBXC292.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E78DFF@TK5EX14MBXC292.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::3]
authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1235;
x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(53754006)(13464003)(76576001)(106116001)(87936001)(74316001)(99286002)(2656002)(230783001)(2561002)(102836002)(107886001)(15975445007)(2950100001)(46102003)(62966003)(77156002)(2501003)(1511001)(86362001)(19580395003)(122556002)(54356999)(92566002)(33656002)(76176999)(2900100001)(561944003)(19580405001)(40100003)(50986999)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1235; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <BN3PR0301MB1235CF5707AF3674706B036ACA1F0@BN3PR0301MB1235.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:BN3PR0301MB1235; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1235;
x-forefront-prvs: 05066DEDBB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2015 18:11:03.3359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1235
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/hbVhxnRkifiwOzMFNT8VJ3Y3_cE>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline
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: Thu, 05 Mar 2015 18:11:09 -0000

This can't be limited to JWE Compact Serialization, we have keys that use the JSON binary serialization.

"cnf" seems underspecified, as this could be a JWK (but not it's not a MUST), and thus I may understand "cnf" but only when used with a JWK and not some other invented structure. So how do I tell what "cnf" really is ?

Is this proposal also limited to a single key  for both asymmetric and symmetric  ?

-----Original Message-----
From: Mike Jones 
Sent: Wednesday, March 4, 2015 3:34 PM
To: Anthony Nadalin; Hannes Tschofenig; oauth@ietf.org
Subject: RE: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

It does so for the same reason that the JWT spec does - to promote interoperability.  We can add wording along the likes of "the JWE Compact Serialization MUST be used" if you like.

				-- Mike

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Wednesday, March 04, 2015 3:26 PM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

Why does the specification state "encrypted to a key known to the recipient using the JWE Compact Serialization" is this the only serialization allowed (there is no MUST) ?
containing the symmetric key.

-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, March 4, 2015 6:41 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline

Hi all,

as the deadline is approaching I would like to close the open issues of the document. There are two open issues listed in the document and I propose ways to resolve them below

Open Issue #1:

"In some conversations, we have said that it is the issuer of the JWT
   that possesses the key, and in some conversations, we have said that
   it is the presenter of the JWT that possesses the key.  Which
   description should we use?
"

There are the following parties in the entire picture (as the PoP architecture document illustrates quite nicely):

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the JWT the issuer needs to compute a digital signature or a keyed message digest over the JWT.

* Presenter: Party that demonstrates possession of a private key (for asymmetric key cryptography) and secret key (for symmetric key
cryptography) to a recipient.

* Recipient: Party that receives the JWT together with the proof of possession of the key (typically in form of a digital signature or a keyed message digest).

Mapping this terminology to the OAuth context would look as follows:
 - Issuer: OAuth Authorization Server
 - Presenter: OAuth Client
 - Recipient: OAuth Resource Server

Adding the above-mentioned terminology to the terminology section (and deleting the currently listed presenter) would resolve the issue IMHO.

Open Issue#2:

Mike added an editorial note to the introduction saying:
"
 [[ Editorial Note: This paragraph needs to be updated to provide more
   context and possibly also to describe the use of asymmetric keys
   instead.  It's not clear that the symmetric case is as useful or
   valuable, and it is certainly more complicated.]] "

The design team work clearly indicated that both symmetric and asymmetric cryptography has to be supported. The JWT mechanism actually supports both and hence we should also describe both. What can, however, be done is to also describe the asymmetric key case and here is my text proposal for the introduction.

----
1.  Introduction

   This specification defines how to bind a key to a JSON Web
   Token (JWT) [JWT]. Three parties act in such a scenario:

* Issuer: Party that creates the JWT and binds a key to the token.
The key may be a symmetric key or a public key. To bind the key to the JWT the issuer needs to compute a digital signature or a keyed message digest over the JWT.

* Presenter: Party that demonstrates possession of a private key (for asymmetric key cryptography) and secret key (for symmetric key cryptography) to a recipient. This property is also sometimes described as the presenter being a holder-of-key.

* Recipient: Party that receives the JWT together with the proof of possession of the key (typically in form of a digital signature or a keyed message digest).

[I-D.ietf-oauth-pop-architecture] describes the use of proof-of-possession semantics for JSON Web Tokens (JWTs) for the use with OAuth.

   Envision the following two use cases. The first use case describes
   the use of a symmetric key and the second use case focuses on
   asymmetric cryptography.

   An OAuth 2.0 authorization server generates a JWT
   and places an encrypted symmetric key inside the newly introduced
   confirmation claim.  This symmetric key is encrypted with a key known
   only to the authorization server and the recipient. The entire JWT
   is then integrity protected.  The JWT is then sent to the
   presenter.  Since the presenter is unable to obtain the
   encrypted symmetric key from the JWT itself, the authorization
   server conveys that symmetric key separately to the presenter.  Now,
   the presenter is in possession of the symmetric key as well as the
   JWT (which includes the confirmation claim member).  When the
   presenter needs to present the JWT to the recipient, it also needs
   to demonstrate possession of the symmetric key; the presenter, for
   example, uses the symmetric key in a challenge/response protocol
   with the recipient.  The recipient is able to verify that it is
   interacting with the genuine presenter by decrypting the JWK
   contained inside the confirmation claim of the JWT.  By doing this
   the recipient obtains the symmetric key, which it then uses to
   verify cryptographically protected messages exchanged with the
   presenter.

   This symmetric key mechanism described above is conceptually similar
   to the use of Kerberos tickets.

   In the second case consider a presenter that generates a public /
   private key pair. It then sends the public key to an OAuth 2.0
   authorization server, which creates a JWT and places an public key
   (or a fingerprint of it) inside the newly introduced confirmation
   claim. The entire JWT is then integrity protected using a digital
   signature to protect it against modifications.

   The JWT is then sent to the presenter. When the presenter needs to
   present the JWT to the recipient, it also needs to demonstrate
   possession of the private key. The presenter, for example, uses the
   private key in TLS exchange with the recipient.  The recipient
   is able to verify that it is interacting with the genuine presenter
   by extracting the public key from the confirmation claim of the
   JWT (after verifying the digital signature of the JWT) and utilizing
   it with the private key in the TLS exchange.

   The asymmetric key mechanism described above is conceptually similar
   to a certificate.

   In both cases the JWT may contain various claims that are included
   based on the policy of the authorization server.

----

Due to the IETF draft submission deadline we would appreciate a response by next Sunday.

Ciao
Hannes




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth