Plugging That Nagging Inbound TCP SYN Packet Security Hole

by Edward Amoroso, TAG Cyber

Our community lost a pioneer last year when Chuck Flink, the inventor of Unix System V/MLS, passed in May. Chuck’s idea was to steal bits from the Unix group identifier construct, which you might recognize as the GUID, to create multi-level security labels in support of a lattice policy model of clearance and need-to-know. Such labeling enabled Unix for sensitive applications requiring mandatory access control. It was a precursor to SE-Linux and SE-Android.

Stealing bits from the GUID was a great idea, because the largely unused structure was there in the operating system, and re-using it for security labels seemed a win-win for everyone involved. Some Unix purists saw the approach as messy, but I always thought it was opportunistic genius, and that more cyber security experts should have studied Chuck’s work more carefully. We are going to miss him.

During a recent technical review with John Hayes, CTO of BlackRidge, I found my mind wandering back to Chuck’s work, because I felt some chilling (and exhilarating) parallels between their work and the GUID designs Chuck coded into Unix. What BlackRidge is doing involves the insertion of identity credential information into the existing TCP handshake, thus changing the sacred Alice-and-Bob dance that’s been with us since Cerf and Kahn first conceived the protocol. I had to ask the guys to repeat their explanation a couple of times, because it seemed inconceivable that after decades of staring at this protocol, that someone might find a new means for enhancing security. But I think the BlackRidge team has done just that.

Anyone who takes a moment to consider the TCP handshake knows that authentication cannot occur until a session is fully established. Policy teams realize this the moment they start coding inbound firewall rules for that new outsourced call center in Elbonia. It becomes obvious immediately that the three-step TCP handshake occurs first, and only then can any supporting required authentication commence. Of course, if the authentication fails, then the result has been an inbound connection that should never have been allowed in the first place. This common scenario has always struck me as a major hole in connection policy enforcement, and has led to weak corresponding safeguards such as source IP-based connection blocking, which can be easily spoofed or bypassed. In short, this problem is messy.

The BlackRidge solution is embedded in a clever technique known generally as Transport Access Control (TAC) and more specifically as First Packet Authentication. What happens is that on a per-session basis, cryptographic identity tokens are inserted into the sequence field of the TCP header for that first SYN packet – the one that has helped firewall engineers put their kids through college. A TAC gateway from BlackRidge sees the first SYN, extracts the crypto token, and then uses it to establish the identity that has been bound to that token. Depending on the policy associated with that identity, the TCP session would be allowed to proceed or would be denied. This functionality allows network security engineers to create trusted domains, thus allowing a better way to check those inbound packets from Elbonia.

One of the great advantages of TAC over similar protocols such as IPSec involves the common headaches that come with network address translation (NAT). As any network security engineer will explain (complain), NAT includes modification of IP addresses and TCP port numbers, which causes numerous operational problems with the IPSec Authenticating Header protocol. In contrast, TAC executes in a transparent manner across networks that employ NAT. It also easily supports man-in-the-middle network or security solutions that would otherwise have trouble dealing with IPSec tunnel mode encryption.

Another great advantage of TAC is that its use of the sequence field in the TCP header results in no operational impact to existing network or security infrastructure. The TAC approach will easily interoperate with any standards-compliant TCP/IP stack, and does not require any changes to endpoints. It also encourages the development and use of multiple administrative domains in an organization. But more than anything else, it closes a logical security weakness that has nagged enterprise security teams for years – namely, this problem of allowing inbound TCP sessions blindly, without regard for authentication policy.

Like those who criticized Chuck Flink’s GUID design for Unix System V two decades ago, there will be those who complain that TAC adjusts a standard protocol in a way that might not have been consistent with its original purpose. I asked John Hayes about this and he acknowledged that this purist view might complicate any goal of turning TAC into a fully-accepted standard or RFC. My advice to the purists is to get over it: Everyone on the planet knows that TCP/IP has been ill-suited to cyber security, so anything that helps should be welcome.

I also know that much of the above discussion might sound like a lot of technical mumbo-jumbo to the less well-informed on network protocols and underlying OSI stack technologies. But perhaps the following non-technical analogy might help: If you want to check the credentials of strangers on the street who would like to enter your kitchen, you could certainly set up a check-in table in your living room, thus allowing entry to your home (i.e., current TCP technology). Or you could take the more sensible route of setting up the table outside your home to check credentials before anyone is permitted to enter your home. This is what TAC does on your network.

I think know which of these two methods I would choose. I don’t like strangers in my living room. Let me know what you think.