Re: [tcpm] TCP-AO review comments.

Joe Touch <touch@ISI.EDU> Mon, 11 August 2008 01:50 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 492C83A6B28; Sun, 10 Aug 2008 18:50:19 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E51A73A6B22 for <>; Sun, 10 Aug 2008 18:50:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id utv7PIcaapbi for <>; Sun, 10 Aug 2008 18:50:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D542A3A6B16 for <>; Sun, 10 Aug 2008 18:50:16 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m7B1nn4S019516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Aug 2008 18:49:56 -0700 (PDT)
Message-ID: <>
Date: Sun, 10 Aug 2008 18:49:08 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Stefanos Harhalakis <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:, "Anantha Ramaiah (ananth)" <>
Subject: Re: [tcpm] TCP-AO review comments.
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

<indiv hat on>

Stefanos Harhalakis wrote:
| On Sunday 10 August 2008, Joe Touch wrote:
|> Stefanos Harhalakis wrote:
|> | Also, is there any good in including a (1-byte - or smaller with some
|> | unused
|> | bits) version field in TCP-AO? This will help similar future
|> | extensions/replacements and will also allow for easier authentication
|> | option
|> | handshaking by falling back to the highest commonly supported method.
|> <indiv hat on>
|> Options don't typically have version numbers; they're implicit in the
|> option KIND itself. IMO, that's why TCP-AO is requesting a new KIND
| Agreed, but since this is a 'group of options' that exclude each
other, a kind
| of initial handshake is inevitable.

Handshakes in this case aren't meaningful.

| As far as I see it, even with just
| TCP-MD5 and TCP-AO there is an initial handshake problem for deciding
| one of them both ends support (no?).

Once a packet contains a TCP MD5 header, it MUST be authenticated using
that option, regardless of other options - thus it is irrelevant to have
alternative options present. That rule basically prevents negotiation of
the TCP MD5 option, or 'escalating' it into TCP-AO.

| Practically this makes the transition
| from MD5 to AO a hard issue.

TCP MD5 made this impossible. TCP-AO permits 'optional' use, i.e., that
the option can be present or ignored on an individual connection, which
may enable future negotiation among a variety of authentication

| Of course a new KIND is required for TCP-AO but I believe that this
should be
| the last one for the "series" of TCP authentication options.

TCP-AO is intended to be sufficiently general - e.g., by the use of a
MAC field which is defined on a per connection basis - that future
updates should not be needed for a long time. That said, there are
plenty of KIND values left if we consume one every 10 years for this

| In fact, this
| may not be considered as a different 'KIND' of options, unless the
| negotiations all authentication options and the SYN-receiver selects
the best
| that it supports. Since this isn't possible with limited TCP options space
| and SYN-cookies issues, something different is required (versioning).
| Do you see another (better) long-term solution?

Overall, since they keys and parameters need to be configured on a
per-endpoint-pair basis anyway, IMO this sort of handshake ought to
occur in the KMS, not in TCP. TCP's SYN option space is insufficient to
contain multiple authentication fields, AFAICT, in addition to the other
fields currently commonly in use.


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

tcpm mailing list