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 15:13 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 72379130ED9; Tue, 26 Jun 2018 08:13:00 -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, 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 yaJqgqzL7vCH; Tue, 26 Jun 2018 08:12:56 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on061a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::61a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85984130E84; Tue, 26 Jun 2018 08:12:55 -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=U9Y/n/VtjFcUlDGmYGqwXwM6bFPJmn/eSYyACDx5jEA=; b=eMQ1wal8egfMO0Xe+gzummtKJuLSfBoUIoAqA61AMp3TUjdHhLepvirkfsDDBAe0MfoJ9aadZpZEcdxg/IHl0sbrVz7ITxZaV9XH7eiB0B25bsgjFDLuLUPPKhz4cvoK0m4q06/fFz5KW9ySFpJ96iZJA3BrKHJN/3CMJ8Xo8GA=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1486.eurprd08.prod.outlook.com (10.167.210.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.21; Tue, 26 Jun 2018 15:12:52 +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 15:12:52 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Mike Jones <Michael.Jones@microsoft.com>, 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+LVoIAAZzsAgAADOlA=
Date: Tue, 26 Jun 2018 15:12:52 +0000
Message-ID: <VI1PR0801MB2112F73E53F790A076D5FFEBFA490@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> <VI1PR0801MB2112F3791E8467A53C440E11FA490@VI1PR0801MB2112.eurprd08.prod.outlook.com> <20180626150003.GD79565@kduck.kaduk.org>
In-Reply-To: <20180626150003.GD79565@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; VI1PR0801MB1486; 7:5edgxC/hCasGZ7dfCdOpDevZmX4MJIYmv8U7O3JquAllV7c2HVg1crnZorx9ruXBuc/Nbt2WnoTZdCRz4l1nQpxF1KhPfWAjoNhgLG6meDocmfLDy5624OFxZ7mIjwokZdbB69mcm1+ubuqX/Q8Mz74AI45hokDnX4QciilO4o1VmlS9GORa+s3c3ka8lVZaZclppPnYaOqXa4w9Fv5EwaV/9aVeX+mj7pa8jD0dwq8jyao6HE+nIABhZJd0gVaJ
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 46e31fd5-c313-4579-38f5-08d5db7749b6
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:VI1PR0801MB1486;
x-ms-traffictypediagnostic: VI1PR0801MB1486:
x-microsoft-antispam-prvs: <VI1PR0801MB1486987569E54AB30C744868FA490@VI1PR0801MB1486.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(223705240517415)(240460790083961);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1486; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1486;
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(346002)(136003)(366004)(13464003)(199004)(40434004)(189003)(3846002)(33656002)(6246003)(54906003)(305945005)(316002)(2906002)(7736002)(8936002)(4326008)(8676002)(105586002)(81166006)(81156014)(74316002)(93886005)(11346002)(486006)(5024004)(6116002)(476003)(14444005)(106356001)(186003)(446003)(256004)(2900100001)(53936002)(2171002)(25786009)(478600001)(53546011)(97736004)(14454004)(76176011)(6436002)(9686003)(229853002)(5660300001)(55016002)(6916009)(68736007)(7696005)(86362001)(102836004)(5250100002)(66066001)(6506007)(26005)(99286004)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1486; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: go4+RifOJj3EMyqtpw319kaGmJVsutuHVQWkH29LX8HkJDqaQsOGKxml4hVuXNOvJd6/l52YK+8j9bZYQpSS2xOuZocpGOJuVlfismf5veIXLXMmSUyeMIctl8KM9Z3dqLqI17V+wBLewvdXqRzUF+AiDwV7Iqd8BIUfX9L+TPwY76OhQx/lWykMFcf56MNKRYDqA8/DX0PtkeBab+bBEC1nT6PCaAM2AObGaDomh6Llt2rhKDTX+VCYzP7Kqd5gmGFbjuIAhVLMDROKpv2Un0UAzx2qnVFyMx6HVkHbeZLKn32upKY8ZKdyGTtzXXXSvVPQIouKZ63Nilt5lr75dc10qx2WoRIeJOmBmS7++/c=
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: 46e31fd5-c313-4579-38f5-08d5db7749b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 15:12:52.6282 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1486
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/kIPm9d4w1KhWijWcnF5CaQCAg5w>
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 15:13:01 -0000

It does answer my question, Ben.

This begs the question why the collision of session keys is suddenly a problem in the ACE context when it wasn't a problem so far. Something must have changed.

Ciao
Hannes


-----Original Message-----
From: Benjamin Kaduk [mailto:kaduk@mit.edu]
Sent: 26 June 2018 17:00
To: Hannes Tschofenig
Cc: Mike Jones; 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 Tue, Jun 26, 2018 at 08:53:57AM +0000, Hannes Tschofenig wrote:
> 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?

I don't believe key collision is an issue in Kerberos.  Long-term keys
(which are not what we're talking about here) are identified by a principal
name, encryption type, and version number.  Session keys that are contained
within tickets (and returned to the client in the KDC-REP) are random, so
even if we are only using the birthday bound we're still in pretty good
shape.  The modern enctypes tend to use subsession keys generated by the
client and/or server as well as the KDC-generated session key, which
provides further binding to the current session.

Does that answer your question?

-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