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

["Sriram Viswanathan \(sriram_v\)" <[e-mail]>]

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

With IPSec, the unique SPI for each of the SA obviates the need for
multiple checks. 
With multiple parallel keys, or during the key transition window (when
both the current SA is within lifetime, and the new SA established), the
SPI is the unique identifier here. 

For TCP-SA, SPI interpretation as  socket pair(IP pair, port pair) will
not be unique for the session. Restarting the session to generate a
different  tuple pair is not acceptable.
To avoid multiple checks, TCP would have to carry the equivalence of SPI
- keyid is one prime example.

Thanks,
Sriram
> 
> > - 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
> 
> 

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