[tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

[Eric Rescorla <[e-mail]>]

$Id: draft-ietf-tcpm-tcp-auth-01-rev.txt,v 1.1 2008/07/28 03:06:22 ekr Exp $

I've reviewed the latest version of this document and while it 
seems to incorporate some improvements over the -00 version,
I still have a number of concerns:

- The document seems to assume an (unspecified) external key management
mechanism. That seems less than maximally useful

- There's discussion of a "per-connection nonce" in S 3.2,
but it's non-normative and does not completely specify how
the nonce is to be used:

     MACs typically benefit from a per-connection nonce, notably in 
     avoiding the impact of key reuse. The presence of TCP's pair of 
     Initial Sequence Numbers presents a nonce that may be useful in that 
     case. Such a nonce could be computed as the concatenation of the ISNs 
     (initiator, responder), and the socket pair (addresses, ports): 
  
     o  Nonce = ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r 
  
     The initial SYN would not know ISN_r, so that packet's nonce would 
     use ISN_r = 0. Use of these nonces avoids the need to avoid key reuse 
     on a per connection basis. 

     >> ISN and socket pair nonces MUST be used to generate unique per-
     session keys. 

   I don't see in the draft where it actually describes how this is 
   intended to work.

- The discussion of key rollover seems incomplete

      >> TCP-AO implementations SHOULD change keys for a connection at 
      least every 2^31 bytes, to avoid resending segments with the same 
      TCP sequence number, data, and length under the same key. 

How is this intended to work?


It seems to me that a useful system needs to describe a complete set
of mechanisms that allow the establishment of a single static key which
can be used to secure multiple connections. I don't see that this 
document does that.




Previous comments which I believe remain outstanding:
S 1.
   there have been escalating attacks on the algorithm itself [Be05] 
   [Bu06].  TCP MD5 also lacks both key management and algorithm 

These citations should be to the original papers, not the summaries
(not that I mind you citing Steve's and my paper...) 

[New: you've added a cite to Burr's paper, but you should be
citing Wang et al.]


S 1.1.
I don't see a lot of value in pre-specifying two MAC algorithms
as MTI. There's no reason to believe one isn't plenty, as used
in other protocols.


S 2.2.
Figure 2 is kind of hard to read since the length of the kind
field is 16 bits, but kinds are 8 bits, rigth?


S 3.
               >> At least one direction (inbound/outbound) SHOULD have 
               a non-NONE MAC in practice, but this MUST NOT be strictly 
               required by an implementation.  

1. This seems like a bad idea. It's very hard to analyze the security
properties of a connection when only one side is protected. To take
one case that is obviously bad, if you're worried about DoS attacks
and you use TCP-AO, then forging packets in either direction can
bring it down. I would reverse this and require MACs in both directions.

2. Even if we stipulate that this might be an OK idea, it's not
appropriate to require implementations to support it.


  
S 9.
   TCP-AO does not expose the MAC algorithm used to authenticate a 
   particular connection; that information is kept in the TSAD at the 
   endpoints, and is not indicated in the header. 

This seems to be of extremely marginal security benefit. There
are likely to be <5 algorithms in use. So, searching all of them
increases the effective key size by <3 bits. 

[New: Again, this isn't a security issue]



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