Subject: [tcpm] "The SYN trick"

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Mar 2008 14:36:51 -0400

I'd suggested using the ISNs as an implicit diversifier for
a single master shared key.

E.g.,

K_connection = HMAC(K_master, ISN_i, ISN_r)

As Joe points out if you use ISNs as an implicit diversifier
for a shared connection key. Obviously, you can't use the 
ISN sound in the SYN/ACK to key the initial SYN. The natural
thing to do here is:

- For the initial SYN use K_connection = HMAC(K_master, ISN_i, 0)
- For subsequent packets use K_connection = HMAC(K_master, ISN_i, ISN_r)

-Ekr

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Brian Weis <[email-masked]>
Date: Tue, 11 Mar 2008 15:55:29 -0400

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.

This implies to me that ISN generation must be a service of the TCP- 
AO module, else the TCP-AO key generation process will not be  
guaranteed to generate good quality K_connection keys. I don't know  
if that's a requirement that can be made in the TCP-AO draft though.

Thanks,
Brian

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Mar 2008 16:25:00 -0400

At Tue, 11 Mar 2008 15:55:29 -0400,
> 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

---

From: Brian Weis <[email-masked]>
Date: Tue, 11 Mar 2008 17:13:31 -0400

Hi Eric,

>       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)

Thanks,
Brian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Mar 2008 18:37:30 -0400

At Tue, 11 Mar 2008 17:13:31 -0400,
> 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