[tcpm] [Repost] Review of the various TCP MACing proposals

I originally sent this to bts, but it should probably be
posted here....

-Ekr

BACKGROUND
----------
There's growing discomfort about the security of TCP MD5
[RFC 2385]. This discomfort comes from a variety of factors:

1. TCP MD5 is an old-style H(Data || Key) design rather
   than a more modern HMAC-style construction.
2. Recent work by Wang et al. has cast doubt on the
   security of MD5 in general and it may be applicable
   to this construction.
3. TCP MD5 doesn't support key rollover, which means
   that rekeying requires tearing down existing connections
   which is a problem for BGP.

There has been a lot of discussion about what to do to 
correct these failings. One obvious strategy (though by
far not the only one) is to produce an improved version
of RFC 2385. This memo discusses three such proposals.

    draft-bellovin-keyroll2385-00		[Be06]
    draft-bonica-tcp-auth-04			[BWVLW06]
    draft-touch-tcpm-tcp-simple-auth-01		[TA06]

Note that there are other architectural options, such as
running everything over IPsec that are not discussed here.
The intent is to discuss merely the proposals which have
a lot of commonality.

COMMON ISSUES
-------------
A number of common issues come up here:

- Use of key identifiers: One natural way to support key rollover
  is to incorporate a key (or association) identifier. This 
  allows the receiving party to determine which key was used
  to protect the received segment. It also provides a potential
  hook for external key management, e.g., via IKE.

- Trial Authentication: If multiple parallel keys are used for
  rollover and a key identifier is not used, then the receiver
  potentially needs to try all the available keys. Concerns
  have been raised about the potential for computation-based
  DoS in such systems.

- Replacement of MAC algorithm: One way to address issues
  (1) and (2) above is to replace the current construction
  with a more modern one such as HMAC. There are actually
  two issues here, the construction and the underlying
  digest.

draft-bellovin-keyroll2385-00
-----------------------------
This draft is only intended to address the key rollover problem. It is
bits on the wire compatible with RFC 2385 and simply provides
algorithms on the receiver and sender side for use and detection of
new keys. No key identifier, so there is a potential for DoS as
indicated above.  The MAC algorithm is not replaced.

Not replacing the MAC algorithm makes me fairly uncomfortable.  The
construction in RFC 2385 is almost certainly weak and is getting
weaker as time goes on. If we're going to go to the trouble of doing
anything I believe that we should replace the MAC algorithm with a
more modern one.

I'm also not sure I think that the receiver-side algorithm proposed
here is the best choice, since it seems designed to allow the use of
multiple keys more or less indefinitely (until the old one is expired)
rather than having a clean cutover after which the old key is no
longer accepted.  ISTM that you could use TCP sequence numbers to
determine a low-water mark after which the old key could no longer be
used.

draft-bonica-tcp-auth-04
------------------------
This draft addresses both the key rollover issue and the MAC
algorithm issue. It creates a new TCP option which includes a key
identifier and has a new MAC algorithm (the mandatory to implement is
AES-128-CMAC-96). The key management system is a fairly complicated
list of static keys with overlapping usable time windows. The new
option also includes optional protection for TCP options (RFC 2385 had
none) and a few other minder features.

My detailed comments can be found on my post about this to SAAG
[Re06]. For the purposes of the discussion here, my major comment
is that I think time-based windows and large keyrings are a bad 
idea and not needed. Key-Ids are quite sufficient.

draft-touch-tcpm-tcp-simple-auth-01
-----------------------------------
This draft is a replacement for RFC 2385 which allows pluggable
MAC algorithms, integrity for the TCP options, and some support
for rekeying (see below). It also provides for more explicit
detail about the interface of the option with TCP.
Otherwise, it is very similar to RFC 2385.

I have two major comments about this draft:

1. Although the MAC algorithms are pluggable, the default is
   HMAC-MD5-96. Given the current status of MD5, I don't 
   believe that the IETF should be standardizing any MD5-based
   algorithms. 

2. I'm not convinced that the rekeying strategy described
   here is OK.

   Note that TCP-SA's support for rekeying is designed to be minimal. As 
   with the IPsec suite, segments carry only enough context to identify 
   the security association [RFC4301][RFC4306]. In TCP-SA, this context 
   is provided by the socket pair (IP addresses and ports for source and 
   destination). The key is identified only in the LSAD, and coordinated 
   by a separate mechanism not specified in TCP-SA. This differs from 
   recent approaches that assume an additional key ID field and require 
   support for multiple concurrently active keys on a single association 
   [Be06][Bo06][We05][We06]. Such complexity is not necessary in TCP-SA 
   because TCP is already robust to segment loss. 

ISTM that this only works properly if the key changes are more
or less synchronized. Consider what happens in the following
sequence of events:

  0s	 A and B are using K1
  10s	 A changes to K2
  60s    A sends data packet
 	 <retries....>
  600s   A gives up and aborts the connection (assume a total timeout
	 of 9 minutes)
  601s   B changes to K2

So, the maximum time difference between A and B rekeying has to
be less than the total timeout. This is plausible with automatic
rekeying, but in cases where it's manual seems difficult. What
happens when A calls B and says "rekey now" but then B decides
to go get a cup of coffee before rekeying? Obviously, it can 
be made to work, but it seems undesirable. 

In order to allow longer gaps between rekeying on the two sides,
you need to support multiple parallel keys.

SUMMARY OF PROPOSALS
--------------------
                          Be06        BWLVW06         TA06
                          --------------------------------
Key Identifiers             No            Yes           No
Trial Authentication       Yes             No           No
New MAC                     No            Yes          Yes

[Be06]    S. Bellovin, "Key Change Strategies for TCP-MD5",
          draft-bellovin-keyroll2385-00.txt, June 2006.

[BWVLW06] R. Bonica, B. Weis, S. Viswanathan, A. Lange, 
	  O. Wheeler, "Authentication for TCP-based Routing
	  and Management Protocols", draft-bonica-tcp-auth-04,
	  February, 2006.	      

[Re06]    E. Rescorla, Message to SAAG Mailing List
	  http://mailman.mit.edu/pipermail/saag/2006q2/001583.html

[RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5
	  Signature Option", RFC 2385, August 1998.

[TA06]    J. Touch, A. Mankin, "The TCP Simple Authentication Option",
	  draft-touch-tcpm-tcp-simple-auth-01.txt, June 2006.

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