Re: [tcpm] public-private keys for TCP-AO

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Tue, 30 October 2018 03:19 UTC

Return-Path: <jheitz@cisco.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1E8127598 for <tcpm@ietfa.amsl.com>; Mon, 29 Oct 2018 20:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 oMBbWC5-azRq for <tcpm@ietfa.amsl.com>; Mon, 29 Oct 2018 20:19:46 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FA51277BB for <tcpm@ietf.org>; Mon, 29 Oct 2018 20:19:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40604; q=dns/txt; s=iport; t=1540869586; x=1542079186; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lY1mcHb6aMTPGNlijLtReZXhr6DUD6O2+fwyOJBpDd4=; b=Lf08CpH6HlJ3csWO48hyub7eVrbkEKkEN3agEfqvBa4r7qbUKe+Enj+K 4n1A+2NhcPAyALBFL0rPIyEJAvggmIMu3iev8a6bqSFkqHHmOtCpk2HDf KrFX9sX5VTA8K+6AxPIBzyLxA8ed0QJLe9SoDuGltF3+euHFOTS5ahYh9 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABjzddb/4ENJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDUgvZn8oCoNriBiMGYINlyCBdwMLAQEYAQq?= =?us-ascii?q?ESQIXgxYhNA0NAQMBAQIBAQJtHAyFOgEBAQEDAQEhCkELEAIBCBEEAQEhAQY?= =?us-ascii?q?DAgICJQsUCQgCBA4FCIMagR1kD6ligS6KHAWLSR4XgUE/hCNZgkIBAYIXgk6?= =?us-ascii?q?CVwKIVxKFYYYiiUlUCQKQeiCNZoJhlnUCERSBJh04gVVwFTuCbIIlAReIXIU?= =?us-ascii?q?+b4wGgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,442,1534809600"; d="scan'208,217";a="462770339"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 03:19:25 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9U3JOXc026555 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 03:19:25 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 22:19:23 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 22:19:24 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Joe Touch <touch@strayalpha.com>
CC: "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] public-private keys for TCP-AO
Thread-Index: AdRv51Oca8SVyggpTLame1T3B/a0kQAME/iAAApbkFD//7O5gIAAU4Pg//+v9oCAAFNQ4P//vwuAgABNFSA=
Date: Tue, 30 Oct 2018 03:19:24 +0000
Message-ID: <eae2d83112e04871ba30bd300f210bce@XCH-ALN-014.cisco.com>
References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> <E4B83487-C832-4F41-BFFE-20CE2EA53AC4@strayalpha.com> <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> <12b0f677e60443d8a32b4d56370787d7@XCH-ALN-014.cisco.com> <4C874E0B-BB5D-4765-8A33-3B9C736B646B@strayalpha.com> <bd707072e91b420d93dd898f69d94898@XCH-ALN-014.cisco.com> <68FFD5DF-E6B1-4E3A-B5F7-AB5114DA1BA0@strayalpha.com>
In-Reply-To: <68FFD5DF-E6B1-4E3A-B5F7-AB5114DA1BA0@strayalpha.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.29.185]
Content-Type: multipart/alternative; boundary="_000_eae2d83112e04871ba30bd300f210bceXCHALN014ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/DZH7ZL7fitVacRTRu6fIdbZjM-w>
Subject: Re: [tcpm] public-private keys for TCP-AO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2018 03:19:49 -0000

Ok.
Shall I write a draft?

Regards,
Jakob.

From: Joe Touch <touch@strayalpha.com>
Sent: Monday, October 29, 2018 7:55 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private keys for TCP-AO

You’d want basically one per connection (the point is to avoid reusing them). You’d be surprised how many connections a pair of endpoints use over time.

Joe


On Oct 29, 2018, at 7:00 PM, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:

There are use cases where I don't need to generate a LOT.
One a month should be just fine, because I have no fear of them leaking into enemy hands.
I posit that distributing one shared secret key is a LOT harder than distributing 1000 public keys.

Regards,
Jakob.

From: Joe Touch <touch@strayalpha.com<mailto:touch@strayalpha.com>>
Sent: Monday, October 29, 2018 6:49 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>
Subject: Re: [tcpm] public-private keys for TCP-AO





On Oct 29, 2018, at 6:41 PM, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:

Because distributing public keys is easier.
Private keys don't need to be distributed. They stay inside the machine that generates them.

Sure, but you need to generate private/public key pairs on both sides of the connection - many of them - and then distribute them to both sides. I.e., the work gets a LOT larger.


Distributing and safe guarding symmetric keys is a major hassle.

Agreed, but you only need one such shared key between each endpoint pair because you can derive session keys algorithmically.

You can certainly TRY to work out the details as you suggest, but I suspect the number of keys needed would be prohibitive even for a single pair of endpoints.

Joe




Regards,
Jakob.

From: Joe Touch <touch@strayalpha.com<mailto:touch@strayalpha.com>>
Sent: Monday, October 29, 2018 6:37 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>
Subject: Re: [tcpm] public-private keys for TCP-AO






On Oct 29, 2018, at 6:22 PM, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:

Can you think of a way to do it that will work?
Like the KDF is just a static list or something.
The sender generates a set of key pairs and numbers them.
It then puts the list of public keys into a file and distributes them to all receivers in the clear.

You’d have to find a way to specify the use of private and public keys on both sides, in advance, and distribute enough for the upcoming connections - then you’d have to hash into that list in a way that avoids reuse. At that point, why not just distribute symmetric keys and be done with it?

Joe

The KDF is just to index into this file.

Because the use case, at least, makes sense.

Regards,
Jakob.

From: Joe Touch <touch@strayalpha.com<mailto:touch@strayalpha.com>>
Sent: Monday, October 29, 2018 6:13 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>
Subject: Re: [tcpm] public-private keys for TCP-AO







On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:

Why was there not a public-private key algorithm specified for TCP-AO? Or did I miss it?

There has not been. I doubt it would make sense (see below).





For example ECC.
An MKT can specify a private key for the sender and a public key for the receivers.

Yes, but the MKT is derived into public/private keys using a KDF.

I am not aware of a KDF that can take a private key and generate a derived private key that would work with a correspondingly derived public key generated from the corresponding public key.

To use, the sender will hash the data, encrypt the hash and put the result into the MAC field.
The receiver would decrypt the MAC field, then hash the data and verify the hash against the decrypted MAC.
This way, the private key never needs to be exposed to anyone, simplifying key management.
Is there any objection to getting this done?

See above; it doesn’t make sense with the way TCP-AO derives keys for each connection, AFAICT.

Joe






Regards,
Jakob.

_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm