Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt

Joe Touch <touch@ISI.EDU> Mon, 21 July 2008 20:45 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 865B73A6AA8; Mon, 21 Jul 2008 13:45:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B497D3A6A76 for <>; Mon, 21 Jul 2008 13:45:26 -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 I779FMoV1i1T for <>; Mon, 21 Jul 2008 13:45:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4F5EE3A68C2 for <>; Mon, 21 Jul 2008 13:45:15 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m6LKjO08021133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Jul 2008 13:45:27 -0700 (PDT)
Message-ID: <>
Date: Mon, 21 Jul 2008 13:44:56 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Adam Langley <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt
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

Hi, Adam,

Adam Langley wrote:
| 2008/7/14  <>:
|> A New Internet-Draft is available from the on-line Internet-Drafts
|>        Title           : The TCP Authentication Option
|>        Author(s)       : J. Touch, et al.
|>        Filename        : draft-ietf-tcpm-tcp-auth-opt-01.txt
| An item which I believe is unclear in the spec:
| Are KeyIDs specific to a single direction? E.g if A and B are
| transmitting with different keys, could they both call them KeyID 0?
| At the moment the wording around the TSAD seems to allow this
| (specifically 6.1).


| Also, comments on the linux netdev mailing list got me thinking more
| about key rotation and I think the spec probably needs a sentence or
| two advising about the use of key rotation.

How often would be in the key management document; we don't specify that.

| The spec currently suggests that rotation occur every 2**31 bytes
| sent. It's not clear if the keys for each direction are assumed to
| rotate independently or not.

They are. The purpose of key rotation based on 2**31 is replay attacks,
not frequency of rotation for other reasons. Others have noted that such
rotation may not be needed with modern HMACs.

| If the directions are independent then a large one-way transfer allows
| an attacker to build up a dictionary of valid ACKs. Since the transfer
| is only one way, the ACKing side will never rotate keys. Thus an
| attacker could step in and convince the sender that everything was
| fine even if the true destination was dead.

The ACKing side needs to rotate keys only when its seqnums rollover, not
the ones it's ACKing.

| If the keys rotate after 2**31 bytes sent or recved there is a
| possible window issue. Consider a host which is sending with a very
| large window over a high delay link. It transmits several key
| rotations worth of data before the first ack comes back from the other
| side. Since this ack was elicited by the beginning of the data, it
| will be transmitted with the first key. If the first key is still
| active, everything is fine, but if the key window has rotated to the
| point where old keys are getting evicted then the ACK will be
| rejected.

The key rotations are supposed to be reasonably synchronized and/or
overlapped to avoid such issues.

| This currently shouldn't be a problem because the max window size is
| 1GB, which is less than 2**31 bytes. At some point in the future, if
| window scaling is allowed to grow past 2**14, then key rotation could
| limit the window size.

This isn't an issue of window scaling; it's an issue of replaying. Keys
are rotated per 2**31 (recommended, at least) based on the rollover of
the seqno; they can be rotated for other reasons as well.

| Given all these questions, I think the spec should make some advisory
| I'm not too sure, but I think I like rotating a per-direction key
| better. The ACK dictionary attack is unfortunate, but if we aren't
| having real sequence numbers then our security is limited at best
| anyway. Based on that I'd suggest a 2-key pair, where, for a
| half-connection from A to B: B RX enables key 1 at 2**30 bytes
| received, A switches to key 1 at 2**31 bytes, B RX enables a new key 0
| at 2**31 + 2**30 bytes, A switches to new key 0 at 2**32 etc. That
| would also mean that KeyIDs are specific to a given half-connection.

They should already be; the TSAD entries are specified per-direction for
that reason.

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

tcpm mailing list