[tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01
Eric Rescorla <ekr@networkresonance.com> Mon, 28 July 2008 04:24 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 [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBDA3A6938; Sun, 27 Jul 2008 21:24:46 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB893A67E7 for <tcpm@core3.amsl.com>; Sun, 27 Jul 2008 21:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.572
X-Spam-Level:
X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbFa-VNq6dLW for <tcpm@core3.amsl.com>; Sun, 27 Jul 2008 21:24:43 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 9AA8D3A6938 for <tcpm@ietf.org>; Sun, 27 Jul 2008 21:24:43 -0700 (PDT)
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id C7A174B7AD3 for <tcpm@ietf.org>; Sun, 27 Jul 2008 21:24:51 -0700 (PDT)
Date: Sun, 27 Jul 2008 21:24:51 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: tcpm@ietf.org
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080728042451.C7A174B7AD3@kilo.rtfm.com>
Subject: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org
$Id: draft-ietf-tcpm-tcp-auth-01-rev.txt,v 1.1 2008/07/28 03:06:22 ekr Exp $ I've reviewed the latest version of this document and while it seems to incorporate some improvements over the -00 version, I still have a number of concerns: - The document seems to assume an (unspecified) external key management mechanism. That seems less than maximally useful - There's discussion of a "per-connection nonce" in S 3.2, but it's non-normative and does not completely specify how the nonce is to be used: MACs typically benefit from a per-connection nonce, notably in avoiding the impact of key reuse. The presence of TCP's pair of Initial Sequence Numbers presents a nonce that may be useful in that case. Such a nonce could be computed as the concatenation of the ISNs (initiator, responder), and the socket pair (addresses, ports): o Nonce = ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r The initial SYN would not know ISN_r, so that packet's nonce would use ISN_r = 0. Use of these nonces avoids the need to avoid key reuse on a per connection basis. >> ISN and socket pair nonces MUST be used to generate unique per- session keys. I don't see in the draft where it actually describes how this is intended to work. - The discussion of key rollover seems incomplete >> TCP-AO implementations SHOULD change keys for a connection at least every 2^31 bytes, to avoid resending segments with the same TCP sequence number, data, and length under the same key. How is this intended to work? It seems to me that a useful system needs to describe a complete set of mechanisms that allow the establishment of a single static key which can be used to secure multiple connections. I don't see that this document does that. Previous comments which I believe remain outstanding: S 1. there have been escalating attacks on the algorithm itself [Be05] [Bu06]. TCP MD5 also lacks both key management and algorithm These citations should be to the original papers, not the summaries (not that I mind you citing Steve's and my paper...) [New: you've added a cite to Burr's paper, but you should be citing Wang et al.] S 1.1. I don't see a lot of value in pre-specifying two MAC algorithms as MTI. There's no reason to believe one isn't plenty, as used in other protocols. S 2.2. Figure 2 is kind of hard to read since the length of the kind field is 16 bits, but kinds are 8 bits, rigth? S 3. >> At least one direction (inbound/outbound) SHOULD have a non-NONE MAC in practice, but this MUST NOT be strictly required by an implementation. 1. This seems like a bad idea. It's very hard to analyze the security properties of a connection when only one side is protected. To take one case that is obviously bad, if you're worried about DoS attacks and you use TCP-AO, then forging packets in either direction can bring it down. I would reverse this and require MACs in both directions. 2. Even if we stipulate that this might be an OK idea, it's not appropriate to require implementations to support it. S 9. TCP-AO does not expose the MAC algorithm used to authenticate a particular connection; that information is kept in the TSAD at the endpoints, and is not indicated in the header. This seems to be of extremely marginal security benefit. There are likely to be <5 algorithms in use. So, searching all of them increases the effective key size by <3 bits. [New: Again, this isn't a security issue] -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Adam Langley
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Adam Langley
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Adam Langley
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Anantha Ramaiah (ananth)
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Anantha Ramaiah (ananth)
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Anantha Ramaiah (ananth)
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Caitlin Bestler
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Joe Touch
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Lars Eggert
- Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt… Eric Rescorla
- [tcpm] tcp-auth-opt issue: replay protection Joe Touch
- Re: [tcpm] tcp-auth-opt issue: replay protection Adam Langley
- Re: [tcpm] tcp-auth-opt issue: replay protection Joe Touch
- Re: [tcpm] tcp-auth-opt issue: replay protection Adam Langley
- Re: [tcpm] tcp-auth-opt issue: replay protection Eric Rescorla
- Re: [tcpm] tcp-auth-opt issue: replay protection Joe Touch
- Re: [tcpm] tcp-auth-opt issue: replay protection Adam Langley
- Re: [tcpm] tcp-auth-opt issue: replay protection Joe Touch
- Re: [tcpm] tcp-auth-opt issue: replay protection Lars Eggert
- Re: [tcpm] tcp-auth-opt issue: replay protection Eric Rescorla
- Re: [tcpm] tcp-auth-opt issue: replay protection Lars Eggert
- Re: [tcpm] tcp-auth-opt issue: replay protection Anantha Ramaiah (ananth)
- Re: [tcpm] tcp-auth-opt issue: replay protection Joe Touch
- Re: [tcpm] tcp-auth-opt issue: replay protection Eddy, Wesley M. (GRC-RCN0)[VZ]
- Re: [tcpm] tcp-auth-opt issue: replay protection Adam Langley
- Re: [tcpm] tcp-auth-opt issue: replay protection Caitlin Bestler
- Re: [tcpm] tcp-auth-opt issue: replay protection Joe Touch
- Re: [tcpm] tcp-auth-opt issue: replay protection Ron Bonica