Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

Mike Jones <Michael.Jones@microsoft.com> Fri, 22 June 2018 20:48 UTC

Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1182130EEB; Fri, 22 Jun 2018 13:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 y9a-hIUicFCT; Fri, 22 Jun 2018 13:48:39 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::71a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6FC130DF5; Fri, 22 Jun 2018 13:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JmWAXjJKWdQEWY7mNT8ZE1KJO6sOPSTq52Qpv3VIyzY=; b=OB6frzsTQ07apau1zhyui3hqlc2rOFGowVHRnZhi6AZJieudeYUKW2qrw4C/oQ/E5Po99nCpCAzCGPWQS1OUZF+j9veZVvE+lB34gDDH9hEBm7OGeR01Hzhq0oMToFXN8VY+HFJMXUsr0dvApGFohUtpYahReLQtV7+Y+7Ejbmw=
Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0315.namprd00.prod.outlook.com (52.132.148.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.931.0; Fri, 22 Jun 2018 20:48:35 +0000
Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d927:b78e:8e51:1747]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::d927:b78e:8e51:1747%2]) with mapi id 15.20.0930.000; Fri, 22 Jun 2018 20:48:35 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
CC: Jim Schaad <ietf@augustcellars.com>, "draft-ietf-ace-cwt-proof-of-possession@ietf.org" <draft-ietf-ace-cwt-proof-of-possession@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
Thread-Index: AQHUCmm+QBbDlvIEiEKYiqnkeWTVYaRsv4gg
Date: Fri, 22 Jun 2018 20:48:35 +0000
Message-ID: <MW2PR00MB02986BC1E87754046C8CDC6AF5750@MW2PR00MB0298.namprd00.prod.outlook.com>
References: <VI1PR0801MB2112C4D6D3CED7C15D9AE886FA750@VI1PR0801MB2112.eurprd08.prod.outlook.com> <20180622204344.GP64617@kduck.kaduk.org>
In-Reply-To: <20180622204344.GP64617@kduck.kaduk.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [8.46.76.24]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MW2PR00MB0315; 7:5rAXeukcn/YsXq5HVvb6tJBwGbGJk43XKB7hDL0likJaO3CoBGXE343zQF70GSQRB9OxvG05vp1hvQP8RPLrZWzQBy8OltGUzGrDWxtLMxJ6rcA9ZNZOY+niWzh79rm/mrNE/1NIdTSNtiUNspqCbJF53RojbfxlwFzPK6J0DGdgh1Uos/UKrwn1w9hMkCGuTqRNlbIOIRwgbiTRf2Bw53LBtpqSABMSSQjECzx7XIwUGx1zf5xbX7w6cIoykeTj
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: bb31e0d3-3ede-4532-a11f-08d5d8818620
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:MW2PR00MB0315;
x-ms-traffictypediagnostic: MW2PR00MB0315:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <MW2PR00MB0315FE8595115CECEBEC3B4AF5750@MW2PR00MB0315.namprd00.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(89211679590171)(192374486261705)(223705240517415)(240460790083961);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3002001)(10201501046)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:MW2PR00MB0315; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0315;
x-forefront-prvs: 071156160B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39380400002)(376002)(39860400002)(396003)(13464003)(189003)(199004)(8990500004)(81156014)(106356001)(66066001)(9686003)(4326008)(6436002)(97736004)(186003)(68736007)(81166006)(2906002)(2171002)(3846002)(6116002)(76176011)(26005)(59450400001)(25786009)(102836004)(105586002)(53936002)(486006)(6246003)(316002)(478600001)(7736002)(3660700001)(7696005)(10290500003)(2900100001)(53546011)(3280700002)(305945005)(5660300001)(11346002)(561944003)(22452003)(5250100002)(10090500001)(72206003)(110136005)(33656002)(6506007)(86612001)(446003)(99286004)(8676002)(14454004)(55016002)(8936002)(229853002)(476003)(54906003)(74316002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0315; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Oo9rV9wLRgPjwVDw9ZLlVh1sDg8aK8HCHog0p23z+HPLU+eBhJkxmiC1sVVxzyArAK/w6gu1zxasvmgXJzFgevEgI6ch9nIrqrycav228vtwFGuhzdBMF7oM/Qk8Md5zdoeDJ1pkFggPyhRulUV3OO6TJm6betFJ5i2ul2mcalkaWLykOcNsd36pKqAtvn5AbXATTvnu41XvztwJHHkrzsV3Wmv5I3mnmDx6rWUx2GafoWIL6ZUTARfNJf/a8nQeUdCnltCkd85VBhxnYL6Ui+V9ZEmEWSsxe0nBjKrJCkGHCR5m9E5W7E3cR6OQAKbo7kZyddl6XIx3Og/6mvn3og==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bb31e0d3-3ede-4532-a11f-08d5d8818620
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 20:48:35.3337 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0315
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/MMKnFSpp7fmLWBA_FDjgjUlSTjA>
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2018 20:48:42 -0000

See my note just now proposing this text to Jim:

"Likewise, if PoP keys are used for multiple different kinds of CWTs in an application and the PoP keys are identified by Key IDs, care must be taken to keep the keys for the different kinds of CWTs segregated so that an attacker cannot cause the wrong PoP key to be used by using a valid Key ID for the wrong kind of CWT."

As long as the PoP keys for different contexts are kept segregated, Key ID collisions or reuse cause no problems.

				-- Mike

-----Original Message-----
From: Benjamin Kaduk <kaduk@mit.edu>; 
Sent: Friday, June 22, 2018 1:44 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>;
Cc: Jim Schaad <ietf@augustcellars.com>;; Mike Jones <Michael.Jones@microsoft.com>;; draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

On Fri, Jun 22, 2018 at 01:36:16PM +0000, Hannes Tschofenig wrote:
> Hi Jim,
> 
> 
> > My problem is that if there are two different people with the same 
> > Key ID,
> either intentionally or unintentionally, then using the key ID to 
> identify the key may allow the other person to masquerade as the first 
> person.  I am unworried about the instance of a failure to get a key based on a key id.
> That is not the problem you are proposing to address.
> 
> -----
> 
> I think we should document this issue. Here is some text proposal that 
> could go into a separate operational consideration section (or into the security consideration section instead).
> 
> "
> - Operational Considerations
> 
> The use of CWTs with proof-of-possession keys requires additional 
> information to be shared between the involved parties in order to 
> ensure correct processing. The recipient needs to be able to use 
> credentials to verify the authenticity, integrity and potentially the confidentiality of the CWT and its content. This requires the recipient to know information about the issuer.
> Like-wise there needs to be an upfront agreement between the issuer 
> and the recipient about the claims that need to be present and what degree of trust can be put into those.
> 
> When an issuer creates a CWT containing a key id claim, it needs to 
> make sure that it does not issue another CWT containing the same key 
> id with a different content, or for a different subject, within the 
> lifetime of the CWTs, unless intentionally desired. Failure to do so may allow one party to impersonate another party with the potential to gain additional privileges.
> "

When would this be "intentionally desired"?  It seems like there would be better ways to share authorization between parties than to issue such duplicate CWTs.

-Ben