Re: [tcpm] "The SYN trick"

Eric Rescorla <ekr@networkresonance.com> Tue, 11 March 2008 22:39 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: ietfarch-tcpm-archive@core3.amsl.com
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A5828C2C9; Tue, 11 Mar 2008 15:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.31
X-Spam-Level:
X-Spam-Status: No, score=-100.31 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 9U9a4vNe3Xf8; Tue, 11 Mar 2008 15:39:53 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD4028C3C1; Tue, 11 Mar 2008 15:39:53 -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 6E78828C3C1 for <tcpm@core3.amsl.com>; Tue, 11 Mar 2008 15:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 tursaq6s+XNi for <tcpm@core3.amsl.com>; Tue, 11 Mar 2008 15:39:50 -0700 (PDT)
Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id 8F0BE28C2E1 for <tcpm@ietf.org>; Tue, 11 Mar 2008 15:39:50 -0700 (PDT)
Received: from dhcp-11ec.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id C79B71AD8B0; Tue, 11 Mar 2008 18:37:30 -0400 (EDT)
Date: Tue, 11 Mar 2008 18:37:30 -0400
From: Eric Rescorla <ekr@networkresonance.com>
To: Brian Weis <bew@cisco.com>
In-Reply-To: <FFDE3AFB-26EC-43A4-AE37-897F0CAA48E4@cisco.com>
References: <20080311183651.BE37B1ACED8@kilo.rtfm.com> <3FD0E4F5-8AA3-427E-BE87-EACAE62AA78D@cisco.com> <20080311202500.F245A1AD5EF@kilo.rtfm.com> <FFDE3AFB-26EC-43A4-AE37-897F0CAA48E4@cisco.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: <20080311223730.C79B71AD8B0@kilo.rtfm.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] "The SYN trick"
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-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 Tue, 11 Mar 2008 17:13:31 -0400,
Brian Weis wrote:
> On Mar 11, 2008, at 4:25 PM, Eric Rescorla wrote:
> 
> > At Tue, 11 Mar 2008 15:55:29 -0400,
> > Brian Weis wrote:
> >>
> >> Hi Eric,
> >>
> >> I like the simplicity of this approach. But using the ISNs to
> >> generate keys requires that the ISN values be generated from good
> >> random numbers (to avoid the generation of predicable keys). I think
> >> most systems today do happen to use a good RNG for generating the
> >> ISN, but there's no guarantee.
> >
> > Actually, this isn't correct, because we're assuming that we have
> > an initial strong key and we're just using the ISNs for diversity.
> > S 6.1.2 of draft-rescorla-tcp-auth-arch-00 goes into this in
> > more detail:
> >
> >    A substantial amount of resistance to inter-connection cut-and- 
> > paste
> >    attacks can be achieved by exploiting connection information other
> >    than the host/port quartet.  For instance, one could start with a
> >    static key and use the TCP ISNs to produce a unique per-connection
> >    key:
> >
> >    K_connection = HMAC(K_static, ISN_client || ISN_server)
> >
> >    If we treat ISNs as random variates (note:  this does not require
> >    cryptographic randomness, just low probability of collisions) then
> >    there are 2^{64} equally probable ISN combinations between any pair
> >    of hosts, which implies 2^{64} potential keys (even if we ignore  
> > the
> >    host/port quartet), so the chance of two connection keys colliding
> >    becomes acceptably low:  on average there will be a collision after
> >    2^{32} connections.  If the host/port quartet is included, then
> >    collisions become even less probable.
> >
> >       Note:  the ISNs are being used here serve the same role as  
> > nonces
> >       in standard cryptographic protocols (e.g., the ClientRandom and
> >       ServerRandom in TLS).  Therefore, the security model explicitly
> >       assumes that they are public information.  Thus, the sequence
> >       number predictability issues described on [RFC1948] do not  
> > impact
> >       the security of the system.  Only nonce uniqueness is required.
> 
> Treating the ISNs as nonces makes a lot of sense.
> 
> But that reminds me that NIST is preparing a draft document (for  
> release one of these days) describing acceptable KDFs based on a  
> secret key. I've been advised that it will recommend including entity  
> identities in the derivation, to tie key derivation to a particular  
> session. So something like the following method might be better:
> 
> 	 K_connection = HMAC(K_master, ISN_i, ISN_r, IP_address_i,  
> IP_address_r, port_i, port_r)

I totally agree.

I have some cryptographic argument that this isn't necessary since
these values get included in the MAC anyway, but I agree that this
is more in line with standard practice.

-Ekr


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm