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

[Joe Touch <[e-mail]>]

EKR wrote:
> I originally sent this to bts, but it should probably be
> posted here....

In case the TCPM folk want to track this, the BTS mailing list is:

https://rtg.ietf.org/mailman/listinfo/bts

That list appears to have been created specifically for this discussion,
so it might be useful to shift the discussion there.

Joe


> 
> -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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tcpm

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