[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
- [tcpm] tcp-auth-opt issue: unique connection keys Joe Touch
- Re: [tcpm] tcp-auth-opt issue: unique connection … Eric Rescorla
- Re: [tcpm] tcp-auth-opt issue: unique connection … Joe Touch
- Re: [tcpm] tcp-auth-opt issue: unique connection … Eric Rescorla
- Re: [tcpm] tcp-auth-opt issue: unique connection … Joe Touch
- Re: [tcpm] tcp-auth-opt issue: unique connection … Eric Rescorla
- Re: [tcpm] tcp-auth-opt issue: unique connection … Joe Touch