Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possession-01: Closing Open Issues before the Deadline
Mike Jones <Michael.Jones@microsoft.com> Wed, 04 March 2015 23:34 UTC
Return-Path: <Michael.Jones@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 757501A0067 for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2015 15:34:37 -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 L1X1yZ4jnAGE for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2015 15:34:35 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467BD1A005C for <oauth@ietf.org>; Wed, 4 Mar 2015 15:34:35 -0800 (PST)
Received: from BY2PR03CA002.namprd03.prod.outlook.com (10.255.93.19) by DM2PR0301MB0624.namprd03.prod.outlook.com (25.160.95.28) with Microsoft SMTP Server (TLS) id 15.1.106.15; Wed, 4 Mar 2015 23:34:33 +0000
Received: from BY2FFO11FD023.protection.gbl (10.255.93.4) by BY2PR03CA002.outlook.office365.com (10.255.93.19) with Microsoft SMTP Server (TLS) id 15.1.106.15 via Frontend Transport; Wed, 4 Mar 2015 23:34:33 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD023.mail.protection.outlook.com (10.1.15.212) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Wed, 4 Mar 2015 23:34:33 +0000
Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.74]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0224.003; Wed, 4 Mar 2015 23:33:52 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Anthony Nadalin <tonynad@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: AQHQVolBIxzQq7Nzg0mQ91i99DI7Cp0M+AcAgAABVsA=
Date: Wed, 04 Mar 2015 23:33:51 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943A2E78DFF@TK5EX14MBXC292.redmond.corp.microsoft.com>
References: <54F71978.5090804@gmx.net> <BN3PR0301MB123410743EF24605A084B1D2A61E0@BN3PR0301MB1234.namprd03.prod.outlook.com>
In-Reply-To: <BN3PR0301MB123410743EF24605A084B1D2A61E0@BN3PR0301MB1234.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.34]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; gmx.net; dkim=none (message not signed) header.d=none;
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(438002)(53754006)(199003)(377454003)(189002)(13464003)(2900100001)(2950100001)(2920100001)(50466002)(46406003)(66066001)(33656002)(561944003)(47776003)(23726002)(2561002)(62966003)(77156002)(54356999)(50986999)(104016003)(2501003)(107886001)(19580405001)(19580395003)(106116001)(55846006)(86612001)(85806002)(2421001)(76176999)(46102003)(230783001)(102836002)(97756001)(86362001)(6806004)(2656002)(87936001)(106466001)(15975445007)(92566002)(1511001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0624; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0624;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Microsoft-Antispam-PRVS: <DM2PR0301MB0624337E4ED56E72312153F4F51E0@DM2PR0301MB0624.namprd03.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002007)(5005006); SRVR:DM2PR0301MB0624; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0624;
X-Forefront-PRVS: 0505147DDB
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2015 23:34:33.1836 (UTC)
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[131.107.125.37]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0624
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/3oW5XUthcISuH0-gSSlWNr1CkxA>
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: Wed, 04 Mar 2015 23:34:37 -0000
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
- [OAUTH-WG] draft-ietf-oauth-proof-of-possession-0… Hannes Tschofenig
- Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possessi… John Bradley
- Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possessi… Anthony Nadalin
- Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possessi… Mike Jones
- Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possessi… Anthony Nadalin
- Re: [OAUTH-WG] draft-ietf-oauth-proof-of-possessi… Mike Jones