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

["Anantha Ramaiah \(ananth\)" <[e-mail]>]

Eric,
   Just a quick observation below..

> 3. TCP MD5 doesn't support key rollover, which means
>    that rekeying requires tearing down existing connections
>    which is a problem for BGP.

Since the TCP MD5 RFC (2385) does not specify about the key change and
the associated actions, implementations tried to do what they liked.
There is no implication that the session needs to go down if the key is
changed. 

It was true that at one point of time when the password (key changed)
the session would be closed and re-opened again by BGP. This has been
corrected by all major BGP implementations. (LDP and MSDP as well,
although I haven't checked)

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