Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05
Joe Touch <touch@ISI.EDU> Sat, 15 November 2008 22:48 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 32A983A680F; Sat, 15 Nov 2008 14:48:27 -0800 (PST)
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 4D1783A680F for <tcpm@core3.amsl.com>; Sat, 15 Nov 2008 14:48:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
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 XNBSFjEUFSLE for <tcpm@core3.amsl.com>; Sat, 15 Nov 2008 14:48:24 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D7F1E3A6805 for <tcpm@ietf.org>; Sat, 15 Nov 2008 14:48:24 -0800 (PST)
Received: from [192.168.1.46] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id mAFMmFLB024660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 Nov 2008 14:48:17 -0800 (PST)
Message-ID: <491F51AF.9090902@isi.edu>
Date: Sat, 15 Nov 2008 14:48:15 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <20081115213338.DD4F57575BD@kilo.rtfm.com>
In-Reply-To: <20081115213338.DD4F57575BD@kilo.rtfm.com>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric, Some clarifying questions below. I think most of these are easy to fix... Joe Eric Rescorla wrote: > $Id: draft-ietf-tcpm-tcp-auth-opt-05-rev.txt,v 1.1 2008/11/15 20:50:05 ekr Exp $ > > Overall, this document is substantially improved. However, > a number of the issues I raised in previous reviews remain: > > OLD ISSUES > In particular, I wrote: > > I don't think this API, specification of the TSAD, etc., is > particularly helpful. IPsec needed the concept of an association > database because packets corresponding to multiple associations > got similar treatment. However, TCP has an explicit notion > of connection so it would be far more convenient to simply > refer to keys as tied to connections, and then have a set > of rules for mapping which connections get which keys. > > Even if some TSAD-type abstraction is useful, I don't think > it's appropriate to define things like the size of each > parameter in the TSAD as opposed to on the wire, or to > describe the default values of various parameters as in > S 3. For instance: > > iii. Key length. A byte indicating the length of the > connection key in bytes. > > Those are internal implementation issues. Certainly, I might > want to use a native int in my implementation. Why should > this document tell me otherwise? > > In response to my previous review, Joe indicated that: > > The TSAD API needs to be specified in detail because the key management > solution needs to rely on that information. > > I don't agree that it's necessary to define *any* API. What's > necessary is to define clear boundaries between the packet processing > system and the key management system (if any). I don't see that it's > necessary to be specified at the level of "this parameter is a byte". > If you want enough specificity that uncooperating implementors could > independently develop these components and have them work together out > of the box, then you need to explicitly define much more material, > i.e., argument order, struct packing, error formats, calling sequences > etc. In other words, you should either be defining language bindings > or a formal language like IDL. Absent that, I don't agree that > defining the length of the fields containing these parameters is of > any value. It's particularly odd to focus on the length of the > parameters and not specify (for instance) the signedness or the > bit order. These would be good reasons to include the signedness (all are unsigned) and byte order (network standard). I don't see a reason to indicate bit order. > WRT to S 3 (now in S 6) I wrote: > > >> 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. > > No good reason has ever been offered for this feature. Given the above > reasoning, I propose it be removed. We covered this in detail in an extended discussion in Philadelphia; it is needed to support channel binding. We can't turn on TCP AO after a connection has started (because TCP has no option handshake after connection establishment), but we can go from using a null algorithm to using a real one. > S 1.1. > o TCP-AO replaces MD5's single MAC algorithm with two prespecified > MACs (TBD-WG-MACS), and allows extension to include other MACs. > > I remain unconvinced that defining two MACs as MTI does anything but > add complexity. You noted this before; I'll raise this to both TCPM and SAAG to confirm that a single algorithm is sufficient. > NEW TECHNICAL ISSUES > Overall > I'm wondering if we should specify heuristics or algorithms for > key changeover. Here's what I mean: Alice and Bob are currently > using Key 1 and they want to change over to Key 2. At time > T0, Alice installs Key 2, but she can't start transmitting with > it until she knows that Bob has installed it. At time T1, > Bob installs Key 2. Now, if he knows that Alice installed first, > he can start using it, but if he does and Alice hasn't, then > packets start getting dropped. Finally, once Bob has installed > Key 2, he needs to tell Alice that he has installed Key 2 > so he can switch over. This is a lot of manual coordination. Agreed; IMO, this is the responsibility of the key management system, not TCP-AO. > Lebovitz and I spent some time the other day trying to make this > problem easier and here's what we came up with. > > 1. As soon as a node receives a segment protected with Key X > (and verifies it, of course) it can conclude that the peer > knows Key X and start using Key X to transmit with. We do not require symmetric key changeover. Side A can use key X while side B uses key Y; there is no requirement that the senders use the same index. > 2. Once a peer has had a new key installed, it should periodically > send a segment protected with that key. Note that the interval > here should be low enough that if the verification fails it > doesn't cause TCP to back off really far. But other than that, > it doesn't matter how it's set. [Maybe there's some TCP wizardry > here to decrease the effect, like you only treat ACKs this way > or something...] This sounds like a protocol on top of TCP; we're trying to avoid that. TCP segments have other meanings, and sending such segments just for a key management reason would impact other TCP properties we're trying to leave alone. > I'm assuming there's some concept of ordering or priority where key > X is assumed to be better (newer) than Y. That seems easy to have. > > Anyway, the point of this algorithm is that Alice and Bob can > independently configure new keys and then the system will automatically > detect when they both have them configured and start using them > without any explicit coordination over when the keys are installed. The common algorithm is: a) install key at receiver b) install key at sender Since our keys are directional, (b) is taken as implicit permission to use that key. I don't see a reason for further key coordination. > S 4. > I found this ESN management algorithm extremely hard to follow. > For starters, no initial values are provided for {SND,RCV}.PREV_SEQ, > which makes it hard to see even where to start. We can initialize those as ISN-1. > Aside from that, let's look at the first line: > > ROLL = (RCV.PREV_SEQ > 0xffff) && (SEG.SEQ < 0xffff); > > Why is 0xffff magic? Sorry - that's a bug. It had been 0x7fff; I had changed it incorrectly in this version. I need to debug that code... ... > Anyway, this algorithm needs much more documentation about why > it's supposed to work. Agreed. > S 5. > Conn_key = TALG(TSAD_key, connblock) > > This is not a good method of generating traffic keys: > > 1. There is no guarantee that the TALG will generate a value as > long as the required key. Indeed, it's easy to design a MAC > where this is not true. For instance, AES-256-CMAC. That point was already raised and needs to be addressed. > 2. What you want to generate a key is a pseudorandom function (PRF) > Not all MACs are PRFs. This is easy to forget because HMAC is > both. However, this is not always the case. Understood; the question is whether we should be specifying separate PRFs, or a PRF that can be based on a MAC. I'd prefer the latter, to allow the PRF to track the addition of new MAC algorithms. Is there a way to do this? ... > Additional reductions in MAC validation can be supported by using a > MAC algorithm that partitions the MAC field into fixed and computed > portions, where the fixed value is validated before investing in the > computed portion. This optimization would be contained in the MAC > algorithm specification. Note that the KeyID cannot be used for > connection validation per se, because it is not assumed random. > > > The use of the term "connection key" and "connection block" are > confusing here because the keys are different in each direction, so > there is no single conn key. I suggest using the term "traffic > key". We don't use those terms in the above paragraph. We might use connection receive key and connection transmit key, but I don't think 'traffic' key is appropriate in a TCP document. > S 8. > >> TCP-AO SHOULD be deployed in conjunction with support for > selective acknowledgement (SACK), including support for multiple lost > segments in the same round trip [RFC2018][RFC3517]. > > I get that SACK would be nice, but this should work fine without > it, so why recommend it here. It helps reduce the overhead of rekeying lost segments. That might be worth mentioning, and we should determine whether this needs to be a SHOULD. > S 8.3 > o TCP connection identifier (ID) (The socket pair, sent as 4 byte IP > source address, 4 byte IP destination address, 2 byte TCP source > port, 2 byte TCP destination port). > > This is incompatible with IPv6--a result of overspecification here. Agreed. > S 9. > >> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for > connections unless not supported by its peer, at which point it MAY > use TCP MD5 instead. > > This seems like a restriction on operators and thus seems inappropriate > to me. That's an artifact of trying to include deprecation of TCP MD5 in this doc; operator guidance seemed needed. If that's not the case, we can remove it... > EDITORIAL > S 3.2. > > The ESN for transmitted segments is locally maintained from a > locally maintained SND.ESN value, for received segments, a local > > This repetition of "locally maintained" is clumsy. Agreed. Will fix. > S 5 > Once a connection is established, a connection key would typically be > cached to avoid recomputing it on a per-segment basis. The use of > both ISNs in the connection key computation ensures that segments > cannot be replayed across repeated connections reusing the same > socket pair (provided the ISN pair does not repeat, which is > extremely unlikely). > > This is only true if strong ISN generation algorithms are used. > This document should come with a SHOULD for using a strong PRNG > for ISN generation. Agreed. > S 8.1. > Keys reused across different socket pairs cannot enable replay > attacks because the TCP socket pair is included in the MAC, as well > as in the generation of the connection key. Keys reused across > > I would use "connnection id" instead of socket pair here. Agreed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkkfUa4ACgkQE5f5cImnZrueBQCYwPODKKQNntnZsZColaK6xCKD EACgmu7LC4ETj56d4wbpyQtu9m2AiEo= =p8bm -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05 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
- [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-05 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