Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01
Eric Rescorla <ekr@networkresonance.com> Wed, 30 July 2008 21:32 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 23CF43A686C; Wed, 30 Jul 2008 14:32:41 -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 3C9A23A686C for <tcpm@core3.amsl.com>; Wed, 30 Jul 2008 14:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.609
X-Spam-Level:
X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_TOOL=2.3, 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 A39tR6kyc1dQ for <tcpm@core3.amsl.com>; Wed, 30 Jul 2008 14:32:39 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id CC9FE3A67A6 for <tcpm@ietf.org>; Wed, 30 Jul 2008 14:32:38 -0700 (PDT)
Received: from host138-59.wifi.conference.usenix.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id B347F4D52E1; Wed, 30 Jul 2008 14:32:53 -0700 (PDT)
Date: Wed, 30 Jul 2008 14:32:53 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <F32F8EC5-70C9-4A7B-A2D2-B00CA43AECFA@nokia.com>
References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <F32F8EC5-70C9-4A7B-A2D2-B00CA43AECFA@nokia.com>
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: <20080730213253.B347F4D52E1@kilo.rtfm.com>
Cc: tcpm@ietf.org, Joe Touch <touch@ISI.EDU>
Subject: Re: [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
At Wed, 30 Jul 2008 14:11:04 +0100, Lars Eggert wrote: > > On 2008-7-28, at 17:40, ext Eric Rescorla wrote: > > At Mon, 28 Jul 2008 08:05:05 -0700, > > Joe Touch wrote: > >> 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. > > > > Well, I think that's a mistake as well. > > > > (1) It's extremely confusing to have two documents. > > (2) There are two issues: > ... > > (3) SAAG has no capability to work on anything, and isn't doing so. > > My recollection of the history here is that the split into an option > part done in TCPM and a keying part done somewhere in the SEC area was > deliberate, and came out of long discussions between TSV, SEC and RTG > folks. But again, it depends what you mean by "a keying part". Here's the general situation that applies with any communication security protocol: - Alice and Bob have long term keys K_a and K_b respectively. - Each individual connetion must have connection keys C_ab and C_ba for transmission between Alice and Bob and Bob and Alice respectively. We need some way to arrange that we start with K_a, K_b and we end up with C_ab, C_ba. For comparison, IPsec solves this problem by having two flavors of key managment: - Null (manual) key management in which K_a, K_b are symmetric keys (actually probably one key) with a static mapping to C_ab, C_ba, e.g.. C_ab = K_a, C_ba=K_b - An automatic key management protocol (IKE) which is run every time an association needs to be set up and which bootstraps K_a, K_b into C_ab, C_ba TCP-MD5 offers a reduced version of the Null model with a single key. draft-bonica and TCP-AO-00 (I'll get to -01 in a minute) in principle support both models, however, as there has been no progress whatsoever on actually doing an automatic key management protocol for this application, that leaves us with the Null model. Again, there's a static key (or perhaps keys) that is used directly as a per-connection key for all connections. The problem with this scheme, as everyone is no doubt tired of hearing me say, is that it is susceptible to a variety of cut-and-paste attacks, both between connections (with the same host/port quartet) and within connections (due to seqno rollover). Now, one could have a number of possible attitudes about this: (A) It's no big deal. (B) We'll live with this for manual keying but we'll deal with it when we finally do automatic keying. (C) We should try to fix it. Given the progress of AKM and the general lack of interest in it from the relevant community, I claim that (B) is more or less the same as (C), at least for the medium term. Now, I personally waver between (A) and (C), but to the extent to which we don't value bits on the wire compatibility, as I observed before, it's possible to remove these problems with TCP-AO without any explicit key management protocol. The solution is to have a set of "key diversification" rules that arrange that even when two packets have the same set of TCP parameters on the wire they are not substitutable. Namely: - Use the ISNs to arrange that different connections have different keys. - Use either an extended sequence number or internal key rollover to avoid cut-and-paste within connections. It should be clear that this sort of technique requires a fairly tight binding between the key diversification/MAC code and the TCP stack, because: - The key computation code needs to know the ISNs for the connection. - If you're using key rollover, then the key computation code needs to know when the seqno rolls over. Now, obviously, you *can* think of this as a particularly dumb form of external key management. I.e., you tell it when you're establishing a new connection and it gives you the key (actually you need *two* interfaces here, because the first packet has to use a 0 ISN for the peer), and then (if using key rollover) you tell it that the ISN rolled over and you would like a separate key. But I think this is unwise for several reasons: - It requires instantiating a new abstraction layer and defining interfaces which are necessarily fairly wide for something which is in principle conceptually quite simple and tightly bound to AO. - These abstractions aren't obviously the abstractions you want for a real (explicit) external key management protocol. - You want the rollover functionality even with an external key management protocol. To expand on the final point, there is no cryptographic reason why you would need to change keys every 2^31 bytes. The *sole* reason is that the TCP seqno is too short. I don't really understand the claimed reasons why an extended sequence number is considered bad, but it doesn't really make sense to call out to the key management system to correct a problem which is TCP-AO, not in the key management, and is common to *every* key management system. Far better to simply define how this works with AO for every key management system and MAC algorithm. I promised I would get to TCP-AO-01, and though it's taken me a long time, here we are. IMHO, TCP-AO-01 reflects the sort of confused interface you end up with when you try to make this unnecessary separation: (1) It suggests how to compute a "nonce" based on the ISNs, but (a) doesn't require this computation algorithm and (b) doesn't specify how one would actually use the nonce with a MAC. The text reads "MACs typically benefit from a per-connection nonce, notably in avoiding the impact of key reuse." Except neither of the most commonly proposed MACs, HMAC or AES-CMAC, uses a nonce, so it's totally unclear how to use this functionality. (2) It suggests key rollover at 2^31 bytes but doesn't describe how to do it. To be clear, if you're using manual key management with key diversification (i.e., without an explicit KMP), then these aren't matters that can be negotiated. Both sides need to simply be configured with how the keys are computed (and diversified) and whether to do key rollover or not. Moreover, again, these issues are largely orthogonal to the choice of MAC. > One motivation was that it seemed unlikely that TCPM needed to be > involved in the details of the keying effort, past the stage of making > sure that the necessary hooks were in place. Given the very tight coupling between TCP and the issues I'm discussing above, I don't really see how TCPM can avoid being involved in these issues. > Unless there are critical reasons to revisit this decision, I'd like > to avoid it. Anything that delays publication of AO isn't helpful at > this point. Well, I'm not suggesting that TCP-AO be specified with a full external KMP. I'm suggesting that it be specified with the above key diversification techniques rather than the current set of vague/confusing hints and a hope that some other document will eventually be specified to fill in the gaps. -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