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