IETF Logo Mail Archive

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

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 26 June 2018 08:54 UTC

Return-Path: <Hannes.Tschofenig@arm.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 7425D130E92; Tue, 26 Jun 2018 01:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 VkFtnGqjJ0bM; Tue, 26 Jun 2018 01:54:05 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0069.outbound.protection.outlook.com [104.47.1.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD63130EC0; Tue, 26 Jun 2018 01:54:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TXiIBQuEnvgQS6QKn4ebkZxTnViVmG3ioEFA6TjB5fM=; b=iMrg+nQxaZKwnHh+hBkhCd3DIs9pff2x5RTa3/tsPVgP0IZwNhmv98gwXirkRGubj1AIUYlG4xCEeynVea0gUGsp2vgHVpZXLPaAJCoaUDocHm09wYa/WrmwS0RIvNN+1/8cF7+pITmaCrEfnD5vZkTh9a0fvWqQr9hViUyBsck=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1535.eurprd08.prod.outlook.com (10.167.210.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.24; Tue, 26 Jun 2018 08:53:57 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::3549:bcde:85fc:e3db%9]) with mapi id 15.20.0884.024; Tue, 26 Jun 2018 08:53:57 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Mike Jones <Michael.Jones@microsoft.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: AQHUCmm7VfkGifo3LEWkTqcB1vlZy6Rsv/OAgAGd44CAA+LVoA==
Date: Tue, 26 Jun 2018 08:53:57 +0000
Message-ID: <VI1PR0801MB2112F3791E8467A53C440E11FA490@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <VI1PR0801MB2112C4D6D3CED7C15D9AE886FA750@VI1PR0801MB2112.eurprd08.prod.outlook.com> <20180622204344.GP64617@kduck.kaduk.org> <MW2PR00MB02986BC1E87754046C8CDC6AF5750@MW2PR00MB0298.namprd00.prod.outlook.com> <20180623212956.GE99689@kduck.kaduk.org>
In-Reply-To: <20180623212956.GE99689@kduck.kaduk.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [80.92.118.234]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1535; 7:OAeUjJlez9mXlIcBMcrNueRk9SpxjQAUw3J0+7LFvzDKrOzHEWjwgJHqFqCkYIHJDquRyM07EJmOJTOXIwQhBgx3/hojwINl2/lRZWGRR6gKlf13K8Clty5qUQxG5xyMLLJLuKFVrEyiwgR+BKD0hrSyT9Z1MjYAzJONYmXcKKE0o1l889GdsVbcDl5vlkskEcWKKcAmmUiz3YnW7iWNanQuTNXknA9nd/qexY9jocfaGCWPrZmtCKmYzuTXtHJx
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: f1e21085-99c8-45c6-7ef6-08d5db425a68
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1535;
x-ms-traffictypediagnostic: VI1PR0801MB1535:
x-microsoft-antispam-prvs: <VI1PR0801MB15352BF8BAFE127854FDAA51FA490@VI1PR0801MB1535.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(223705240517415)(240460790083961);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231254)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1535; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1535;
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39860400002)(136003)(366004)(13464003)(189003)(199004)(40434004)(3846002)(8936002)(74316002)(6116002)(8676002)(7736002)(305945005)(81166006)(68736007)(14454004)(81156014)(105586002)(476003)(33656002)(11346002)(446003)(486006)(106356001)(5660300001)(2906002)(6246003)(53936002)(2171002)(55016002)(9686003)(53546011)(2900100001)(4326008)(186003)(54906003)(93886005)(25786009)(102836004)(478600001)(5250100002)(6436002)(6506007)(26005)(229853002)(86362001)(66066001)(316002)(97736004)(72206003)(1511001)(76176011)(99286004)(110136005)(7696005)(5024004)(14444005)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1535; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: LnQc6HzushUg5bKgblgfQf5uC/VWRryUqS194U23dqUeeu1Pv2hpuq+2yOKkMUO3SJkcyjq1YAnfWUaLFrwKpbjMUolsMc3rYgGoNwRghDmGaPC52kTfJWMxf9u/EPAyRuDC0NMs1hUCF1STACafbZkp/nyUQYE/9XzDAMgESTLopjPGlqST9lvBSCyGFSx20Mp6Vjhco5zLLdhVc4vkQ7bz6Rl+8DallCgsp9d6wACWsomZIR6ZAPsBHjmEjTiN3dpx8/P4sMc13SRGqQIGSQXX2hEYDSOPRVU3PNgC/7udnheYFX+HvrgsFIGLuzwpXkyZUI4J28T6/ayE/pSA0CwF/c37djCrFL72s8BaYcs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f1e21085-99c8-45c6-7ef6-08d5db425a68
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 08:53:57.2509 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1535
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ujrkZRgPEJe-NWGBDyZg9g0mKoE>
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: Tue, 26 Jun 2018 08:54:08 -0000

Ben,

I was wondering whether the situation is any different in Kerberos. If the KDC creates tickets with a session key included then it needs to make sure that it does not create the same symmetric key for different usages.
The key in the Kerberos ticket is similar to the PoP key in our discussion.

Are we aware of key collision in Kerberos?

Ciao
Hannes

-----Original Message-----
From: Benjamin Kaduk [mailto:kaduk@mit.edu]
Sent: 23 June 2018 23:30
To: Mike Jones
Cc: Hannes Tschofenig; Jim Schaad; 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 08:48:35PM +0000, Mike Jones wrote:
> 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.

If we trust everyone to implement things properly.  We should probably only
take that risk if we get some other benefit from it, though.  Jim mentioned
(off-list?) a scenario involving giving the same client additional
privileges, and of course we can gain some simplicity savings if we don't
need to enforce global key-id uniqueness (for appropriate values of
"global").  So this may well be the right thing to do; I just don't think
it's without tradeoffs as your text seems to imply.

-Ben
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

v2.23.0 | Report a Bug | By Email