[tcpm] Comments on draft-ietf-tcpm-tcp-auth-opt-00

[Eric Rescorla <[e-mail]>]

I started writing comments on this and after I'd spent about 
2 hours writing background material, I decided to cram it 
into an I-D. Until it appears on the I-D directory, you
can find it at:

https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tcp-auth-arch.txt

Anyway, review follows:

$Id: draft-ietf-tcpm-tcp-auth-opt-00-rev.txt,v 1.2 2008/03/10 23:11:21 ekr Exp $

GENERAL COMMENTS
I'm not convinced it's necessary to have a new key for each
connection. This is primarily useful to prevent inter-connection
cut-and-paste attacks, and it's not clear how serious those
are. I think it's particularly problematic to levy this
requirement without providing some mechanism for arranging
that, since that basically implies having some automatic
mechanism for establishing fresh per-connection keys, which
doesn't currently exist. That makes this mechanism distinctly
less useful than RFC 2385.

I don't think this API, specification of the TSAD, etc., is
particularly helpful. IPsec needed the concept of an association
database because packets corresponding to multiple associations
got similar treatment. However, TCP has an explicit notion
of connection so it would be far more convenient to simply
refer to keys as tied to connections, and then have a set
of rules for mapping which connections get which keys.

Even if some TSAD-type abstraction is useful, I don't think
it's appropriate to define things like the size of each
parameter in the TSAD as opposed to on the wire, or to
describe the default values of various parameters as in
S 3. For instance:

         iii. Key length. A byte indicating the length of the 
               connection key in bytes.  

Those are internal implementation issues. Certainly, I might
want to use a native int in my implementation. Why should
this document tell me otherwise?


TECHNICAL COMMENTS
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.
This thing with the key-id being present if the MAC is odd,
but absent if it's even strikes me as being overly clever.
Let's just burn an octet on key-id and leave it at that.

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 4.1.
   >> New TSAD entries MUST be checked against a table of previously 
   used TSAD entries, and key reuse MUST be prohibited. 

Huh? So, I have to keep a list of every TSAD entry ever and check
against the table. Seems better to just to do this by construction.

S 4.3.
   >> TCP segments with TCP-AO but not matching TSAD entries MUST be 
   silently accepted; this is required for equivalent function with TCPs 
   not implementing TCP-AO.  

I don't see this. Can you explain?

   >> Silent discard events SHOULD be signaled to the user as a warning, 
   and silent accept events MAY be signaled to the user as a warning. 

I don't really understand what a warning means here? syslog? 

S 5.
   Implementations are encouraged to keep keys in a suitably private 
   area. Users of TCP-AO are encouraged to use different keys for 
   inbound and outbound MACs on a given TCP connection. 

Some discussion of why different keys are good or bad would help
here. As far as I can tell, reflection attacks aren't an issue
as long as the host/port quartet is incuded in the header.

S 5.1.
   o  Number of bytes to be sent/received (two bytes); this is used on 
      the send side to trigger bytecount-based KeyID changes, and on the 
      receive side only for statistics or length-sensitive KeyID 
      selection. 

Please explain the cryptographic rationale for why you would want to
do bytecount based key changes.

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. 


EDITORIAL COMMENTS
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...)

o
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.
   Note that the connection key is not included here; we expect that the 
   MAC algorithm will indicate how to use the key, e.g., as HMACs do in 
s/HMACs do/HMAC does/


   TCP-AO by default includes the TCP options because these options are 
   intended to be end-to-end and some are required for proper TCP 
   operation (e.g., SACK, timestamp, large windows). Middleboxes that 

I dpn't understand what "by default" means here. This needs to be
configured on both sides, right? So, this is just a UI issue.

S 5.
   the default case. Segments carry only enough context to identify the 
   security association [RFC4301][RFC4306]. In TCP-AO, this context is 

I'm not sure what security association means here. You're not using IKE,
right?


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. 

I may not be enough of a TCP wonk, but what's a connection ID?

-Ekr

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