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

Joe Touch <touch@ISI.EDU> Thu, 31 July 2008 06:30 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 524653A6A8D; Wed, 30 Jul 2008 23:30:51 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 030B23A6BFE for <>; Wed, 30 Jul 2008 23:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.193
X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_47=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o7Vo0XxZRlzc for <>; Wed, 30 Jul 2008 23:30:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E6EA43A6A8D for <>; Wed, 30 Jul 2008 23:30:48 -0700 (PDT)
Received: from [] ([]) by (8.13.8/8.13.8) with ESMTP id m6V6UOmQ024200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 23:30:26 -0700 (PDT)
Message-ID: <>
Date: Wed, 30 Jul 2008 23:29:49 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Eric Rescorla <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [tcpm] tcp-auth-opt issue: unique connection keys
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Hash: SHA1

Eric Rescorla wrote:
| At Wed, 30 Jul 2008 15:42:38 -0700,
| Joe Touch wrote:
|> 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?
| Why does this prohibit simultaneous open? Because you're assuming
| that there's only one possible key for a given host/port quartet?

The difference between #1 and #2 is that #2 overwrites the TSAD entries
with the hash. Yes, the issue with simultaneous opens is the need for
multiple keys per "host/port quartet" (can we call that a socket pair,
as per 793?).

<individual hat on>
We could also keep multiple keys just in case there's a simultaneous
open, until at least the SYN-ACK is received on a given side (at which
point we can drop the extra keys).

	origkey = as installed by KMS
	SYNkey = hash(origkey, src_ISN) computed when SYN is sent
		before an incoming SYN is rec'd (by either side)
	connkey = hash(origkey, src_ISN, dst_ISN)
		computed when the ack of the SYN is rec'd or
		an incoming SYN is ack'd

only the connkey can overwrite the origkey in the TSAD. for space
reasons, we don't want to keep too many keys around.

If we prepend the ISNs to the data, we avoid separate calls to the MAC
algorithm during the three-way handshake, but we keep reprocessing the
ISNs for each packet sent.
<individual hat off>

So at this point both #1 and #2 could support simultaneous opens. Which
method is preferable and why?


Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list