Re: [tcpm] "The SYN trick"

[Brian Weis <[e-mail]>]

Hi Eric,

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)

Thanks,
Brian

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

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: [phone]
Email: [e-mail]

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