Re: [tcpm] "The SYN trick"

Eric Rescorla <ekr@networkresonance.com> Tue, 11 March 2008 20:29 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 2A08128C652; Tue, 11 Mar 2008 13:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.282
X-Spam-Level:
X-Spam-Status: No, score=-100.282 tagged_above=-999 required=5 tests=[AWL=0.155, 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 TNoIK2ABCr0Q; Tue, 11 Mar 2008 13:29:04 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D925628C4F3; Tue, 11 Mar 2008 13:28:44 -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 CC6173A682C for <tcpm@core3.amsl.com>; Tue, 11 Mar 2008 13:28:43 -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 jS-pv9d8QQuh for <tcpm@core3.amsl.com>; Tue, 11 Mar 2008 13:28:43 -0700 (PDT)
Received: from kilo.rtfm.com (dhcp-11ec.ietf71.ietf.org [130.129.17.236]) by core3.amsl.com (Postfix) with ESMTP id C0A9F28C4FF for <tcpm@ietf.org>; Tue, 11 Mar 2008 13:27:20 -0700 (PDT)
Received: from dhcp-11ec.ietf71.ietf.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id F245A1AD5EF; Tue, 11 Mar 2008 16:25:00 -0400 (EDT)
Date: Tue, 11 Mar 2008 16:25:00 -0400
From: Eric Rescorla <ekr@networkresonance.com>
To: Brian Weis <bew@cisco.com>
In-Reply-To: <3FD0E4F5-8AA3-427E-BE87-EACAE62AA78D@cisco.com>
References: <20080311183651.BE37B1ACED8@kilo.rtfm.com> <3FD0E4F5-8AA3-427E-BE87-EACAE62AA78D@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: <20080311202500.F245A1AD5EF@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 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.

   This scheme has very similar security properties to the scheme
   described in Section 6.1.1, including having a compatible key
   management interface.  Unlike static keys, however, there is a
   significant amount of resistance to inter-connection cut-and-paste
   attacks because each connection with high probability uses a unique
   key.

-Ekr

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