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

Benjamin Kaduk <kaduk@mit.edu> Tue, 26 June 2018 15:14 UTC

Return-Path: <kaduk@mit.edu>
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 11238130E8E; Tue, 26 Jun 2018 08:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 RqQtABxHbgPF; Tue, 26 Jun 2018 08:14:24 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D731130DFD; Tue, 26 Jun 2018 08:14:23 -0700 (PDT)
X-AuditID: 1209190e-a39ff700000072da-fc-5b32584ed4f4
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 44.9D.29402.E48523B5; Tue, 26 Jun 2018 11:14:22 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w5QFEKdR029869; Tue, 26 Jun 2018 11:14:21 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5QFEGnf018836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jun 2018 11:14:18 -0400
Date: Tue, 26 Jun 2018 10:14:16 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
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>
Message-ID: <20180626151415.GE79565@kduck.kaduk.org>
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> <VI1PR0801MB2112F73E53F790A076D5FFEBFA490@VI1PR0801MB2112.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <VI1PR0801MB2112F73E53F790A076D5FFEBFA490@VI1PR0801MB2112.eurprd08.prod.outlook.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hTV1vWLMIo2OPPLyuL7tx5mi5//rjNb 3Jxxisli9fTvbBZ7p31icWD1WDNvDaPHxjnT2TyWLPnJ5NG64y97AEsUl01Kak5mWWqRvl0C V8bZjq1MBZsFK56dz25g/MvbxcjBISFgIvF2dmYXIxeHkMBiJolZhz+wQTgbGSVOfdrMCOFc ZZI4NfsEexcjJweLgKrEpoW72EBsNgEViYbuy8wgtoiAocTe5kOsIA3MAh8YJS5suMkCkhAW CJN48mAtI4jNC7Tu/+fL7BBTHzFL3DqzkxkiIShxcuYTsAZmAS2JG/9eMoHcxywgLbH8HweI ySmQKNG+KxWkQlRAWWJv3yH2CYwCs5A0z0LSPAuheQEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy8 1CJdY73czBK91JTSTYzgsJbk28E4qcH7EKMAB6MSD6+Bk1G0EGtiWXFl7iFGSQ4mJVHeD85A Ib6k/JTKjMTijPii0pzU4kOMEhzMSiK8x94aRgvxpiRWVqUW5cOkpDlYlMR5sxcxRgsJpCeW pGanphakFsFkZTg4lCR4y8KBhgoWpaanVqRl5pQgpJk4OEGG8wANPxcGVMNbXJCYW5yZDpE/ xajL8e/m/l5mIZa8/LxUKXFec5BBAiBFGaV5cHNA6Ugie3/NK0ZxoLeEeXtAqniAqQxu0iug JUxAS8oeG4AsKUlESEk1MLL7bCl1zdyrwtCrvf9klVH0vlNH6iwYVup7eDG+1BLJePfPPyD5 1b3P7PdnmJQpNZx82O30/3japVCRpUeeValu3u9/eNc0gecLTu5lsWf8/mra/Exp/WjBqQzy U/p+CP7nZFAymxp4w/j2m5STBl9EhO6/Vz7+unJxZi+bVYZhEF/vLv+jV5VYijMSDbWYi4oT ARsWJhoiAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/mMtRCPakUD--sy8e6K2j9-xfVBo>
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:14:26 -0000

I thought we were worried about collision of key *identifiers*, which were
not necessarily raw keys or hashes thereof.  But it's possible I was not
paying enough attention and got confused.

-Ben

On Tue, Jun 26, 2018 at 03:12:52PM +0000, Hannes Tschofenig wrote:
> 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.