[tcpm] tcp-auth-opt issue: replay protection

Joe Touch <touch@ISI.EDU> Wed, 30 July 2008 22:23 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 [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id 235EA3A69EE; Wed, 30 Jul 2008 15:23:30 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 0BEB03A69EE for <tcpm@core3.amsl.com>; Wed, 30 Jul 2008 15:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id D7vsigGO40dQ for <tcpm@core3.amsl.com>; Wed, 30 Jul 2008 15:23:28 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu []) by core3.amsl.com (Postfix) with ESMTP id 329C33A69E7 for <tcpm@ietf.org>; Wed, 30 Jul 2008 15:23:28 -0700 (PDT)
Received: from [] (c1-vpn7.isi.edu []) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UMNDx0000943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 15:23:16 -0700 (PDT)
Message-ID: <4890E9AE.3000607@isi.edu>
Date: Wed, 30 Jul 2008 15:22:38 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: tcpm@ietf.org
References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <F32F8EC5-70C9-4A7B-A2D2-B00CA43AECFA@nokia.com> <20080730213253.B347F4D52E1@kilo.rtfm.com>
In-Reply-To: <20080730213253.B347F4D52E1@kilo.rtfm.com>
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: replay protection
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

Hash: SHA1

Given Eric's points on this topic, as a way forward, there are a few
alternatives (comments requested)

1. assume the key management system (KMS) will rollover the keys every
2^31 bytes

	Eric noted this is weak, since we cannot rely on the KMS
	to act on this without other info. Let's presume this
	is unacceptable to the WG and move on...

2. include an extended sequence number (ESN) inside TCP-AO
	ESN starts at 0
	increment ESN when the TCP sequence number rolls over*
	passed ESN to the encryption algorithm as part of the MAC'd data

3. have TCP-AO ask the KMS to add a new key for the connection when the
sequence number rolls over (actually just before, e.g., 2^31 rolls over)

- ------------------------------------

#2 is internal to TCP-AO, i.e., it requires no 'callback' to the KMS
There appears to be a synchronization issue here - exactly when is the
ESN incremented? Suppose endpoints A and B; there are two ESNs - ESN_ab
and ESN_ba:
	A increments ESN_ab when A receives an ack from B w/seqno > 2^31
	B increments ESN_ab when B sends an ack to A w/seqno > 2^31
	B increments ESN_ba when B receives an ack from A w/seqno > 2^31
	A increments ESN_ba when A sends an ack to B w/seqno > 2^31
i.e., the ESN is incremented when the reverse channel succeeds; we can't
use the forward channel, since one side would change the ESN in ways the
other would never notice (it wouldn't decode it)

Given that algorithm, every ESN increment would trash data in transit
from A-B. Is there an algorithm that does not do this?

- -------------------------------------

#3 allows packets to be reordered without loss during key rollover, and
is not susceptible to the burst-losses of #2

Note that #2 should not 'insert a key into the TSAD' - that interface
should be under the exclusive control of the KMS - at which point asking
the KMS to keep that info (or bury it in the TSAD where the KMS can
refer to it) seems sufficient.

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

tcpm mailing list