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

EKR wrote:
> 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.

Where is that key ID in IPsec AH?

There's only an SPI, the SPI indexes a database with the key ID, which
can change via a separate (IKE) protocol.

In TCP-SA (simple-auth), we use the same principle:
	where SPI -> socket pair (IP pair, port pair)

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

How is this handled in IPsec/IKE?

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

The issues with MD5 are constrained to non-HMAC uses. The security
community, AFAICT still suggests HMAC-MD5. HMAC-MD5 is much faster than
HMAC-SHA1

> 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

We do assume rough synchronization, and note that there will be packet
loss during the rollover. A key resynch that spans 9 minutes will break
lots of things.

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

That depends on the implementation of the LSAD updates; one can design
the implementation to make new keys active at a scheduled time in the
future. That means that the clocktime on each system then becomes a
security issue, though.

> 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

This summary doesn't address the need for integrated key management, the
 effect on TCP's timers and window mechanisms, and the impact on TCP's
state diagrams. IMO, those are as - if not more - important considerations.

Joe

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

Attachment: signature.asc