Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

Joe Touch <touch@ISI.EDU> Mon, 28 July 2008 15:06 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 844CB3A691C; Mon, 28 Jul 2008 08:06:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DC5B3A691C for <>; Mon, 28 Jul 2008 08:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.459
X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nnLzrDfnO7Jp for <>; Mon, 28 Jul 2008 08:05:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E86FC3A6895 for <>; Mon, 28 Jul 2008 08:05:56 -0700 (PDT)
Received: from [] ([]) by (8.13.8/8.13.8) with ESMTP id m6SF5a3p017817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 08:05:39 -0700 (PDT)
Message-ID: <>
Date: Mon, 28 Jul 2008 08:05:05 -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] Review of draft-ietf-tcpm-tcp-auth-opt-01
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:
|> | Regardless of whether there is a KMP, it strikes me as unwise to
punt this
|> | job to it.
|> There is a KMP; it is required (and we can't move forward to submit this
|> as final until there is).
| Well, as I've indicated previously, I don't agree that a KMP is
| required or desirable. It's quite straightforward to make this system
| work with a single, pairwise, static key, provided you have an
| appropriate key diversification mechanism. If you want to call that a
| KMP, I suppose you could, but since it doesn't require actually
| exchanging any messages, I would not do so.

OK; we're dancing around terms here. TCP-AO uses a _separate_ document
to specify the out-of-band key mechanism. What that includes can be
discussed in that context - e.g., on SAAG.

| If your assertion is that a KMP is required to make this protocol
| useful, given that (1) there's no draft for such a KMP on the
| horizon and (2) the most likely consumers of this draft, the
| routing/ops community, seem to have no interest in doing a KMP,
| then I think this raises serious questions about the viability
| of this approach.

The "KMP" (or whatever we're calling it) should be underway in SAAG; if
it has stalled, then we'll address that issue off-list.

|> | The TCP authentication protocol should be able to provide security for
|> | packets even in the face of sequence number rollover, out to the
|> | limits of security of the MAC algorithm (which far exceed 2^31 bytes
|> | in both cases). There are (at least) two potential approaches:
|> |
|> | 1. Use a (synthetic) extended sequence number.
|> We discussed this, but there are concerns with interactions with TCP. We
|> don't want to add separate, coordinated state outside the existing TCP
|> state mechanism.
| Uh, ok... It's not like this doesn't need to be tightly coordinated
| with TCP in any case.
|> | 2. Change the key used to compute the MAC inside the protoco.
|> Can you explain this?
| Sure. You have a per-connection key. Every time the sequence number
| rolls, you run the KDF again to generate a fresh per-connection key.
| No KMP required. (This meshes with my previous key diversification
| comments).

That's burying the key generation protocol inside TCP-AO. My
understanding is that this is the reason for an external mechanism,
whatever it is called, and regardless of whether it explicitly or
implicitly coordinates with the other end (you're referring to implicit

|> | But I don't think it's a good idea to punt this to the KMP, since
|> | you don't really need to change the key for any cryptographic reason.
|> If there's no cryptographic reason, why would we need to change the key
|> at all? I.e., isn't the need for a unique per-packet nonce a
|> cryptographic requirement (if not, why do we care?)
| There is no need for a unique per-packet nonce.

If so, then why generate fresh keys on rollover?

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

tcpm mailing list