[tcpm] tcp-auth-opt issue: unique connection keys

Joe Touch <touch@ISI.EDU> Wed, 30 July 2008 22:43 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6548D3A6A15; Wed, 30 Jul 2008 15:43:19 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DC73A6A17 for <tcpm@core3.amsl.com>; Wed, 30 Jul 2008 15:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXB0gmuzYSvj for <tcpm@core3.amsl.com>; Wed, 30 Jul 2008 15:43:16 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B6F4D3A6A15 for <tcpm@ietf.org>; Wed, 30 Jul 2008 15:43:16 -0700 (PDT)
Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UMhCTC009035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 15:43:15 -0700 (PDT)
Message-ID: <4890EE5E.2000400@isi.edu>
Date: Wed, 30 Jul 2008 15:42:38 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: tcpm@ietf.org
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Subject: [tcpm] tcp-auth-opt issue: unique connection keys
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric has raised the point that we should expect the TCP-AO system
(TCP-AO and its required key management system [KMS]) to ensure unique
connection keys.

draft-01 outlines the information that would be used to provide this
information (i.e., derivative of the ISN, etc.).

Eric raised concerns about whether this function can reasonably be
external to TCP-AO (e.g., inside the KMS) or inside the KMS, and about
the vagueness of the description. The current document was intended as a
starting point for that discussion, FWIW.

One observation is that the KMS manages keys for connections - i.e., the
socket pair (addr/port pair) - but has no info on ISNs. It can establish
keys for that socket pair in the TSAD, but cannot generate appropriate
session keys in advance of a connection being established.

Let's assume that the KMS includes the socket pair in the connection key
when it inserts it into the TSAD (or that this can occur trivially for
wildcard source port entries by re-hashing with the appropriate port
when the first packet instantiates the entry). As a result, the ISNs are
the only missing component to the connection key.

As was suggested before, use ISNs as follow:

	SYN (without ACK) - use src_ISN from SYN, dst_ISN=0
	all other packets - use src_ISN, dst_ISN from first SYN rec'd

There are (at least) two ways to achieve this:

1) prepend src_ISN, dst_ISN to each incoming packet for MAC calculation

2) overwrite the TSAD keys established by the KMS
	i.e., on first SYN emitted
		key=hash(key, src_ISN)
	on SYN-ACK received
		key=hash(key, dst_ISN)

#1 has the advantage that it appears to work for simultaneous open, in
which the SYNs are keyed based on different ISN info in each direction,
but are received properly

#2 reduces the per-packet cost by the length of two ISNs, by investing
in the hash at connection establishment. However, it appears to prohibit
simultaneous open. Can anyone suggest a solution that supports
simultaneous open?

- -----

Comments?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiQ7l0ACgkQE5f5cImnZru5oQCg34uLab9rSv+VUWGvHen/XVrH
9f4An0DYlyLl0Cxb29CgPcyjQPtJKjjx
=Tzqz
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm