This document proposes adding Diffie-Hellman key exchange and digital signatures to the TCP three-way handshake to provide assured identity continuity for TCP connections even when network address translation (NAT) is used. It aims to prevent IP spoofing attacks by allowing endpoints to validate each other's identities during a TCP connection. The proposal outlines adding the cryptographic operations to the TCP handshake in a way that is incrementally deployable and backwards compatible without requiring any pre-existing relationship between endpoints. It also discusses some proof-of-concept implementation issues regarding using iptables and packet manipulation to verify signatures on TCP payloads.

1. Signed Sessions Spoil Spoofing:Building assured ephemeral identity continuity into TCP Jim MacLeod, @shewfig BayThreat 2010 shewfig.blogspot.com

2. Stealing my own Thunder Embed Diffie-Hellman in TCP SYN exchange Create ephemeral shared secret Maybe sign DH using RSA/DSA Lightweight signature Hash every packet in TCP stream on send Verify on receive If no signature: assume spoofed/injected: drop Transparent to high-level app: Tie in through iptablesipq/nfqueue

3. The Problem IP spoofing Injected content / hijacking Injected control / RST spoof (cf. RFC 4953) FW rule evasion Results Session hijacking: steal credentials Info injection: SSL re-negotiation attack BGP TCP RST injection: routes marked as invalid

4. Comparison Swap people during conversation http://www.youtube.com/watch?v=vBPG_OBgTWg IP spoofing does the same thing with TCP/IP We want to know if the switch occurs! Almost never a good thing.

5. Level of paranoia Spoofing can be on-path or off-path Off-path Can’t sniff packets, attacks are blind Can pull state info from either endpoint, but cross-connection states have been randomized (to counter this!) On-path In the packet path, or same subnet* as an endpoint Can sniff, can inject, can potentially MitM Coffee-shop WiFi, office network, cable modem, hotel… AnywhereFireSheep would work These networks are often behind NAT

6. The Scope Provide session continuity assurance Endpoints can validate each other during transitory conversation Arbitrary endpoints Could be on opposite ends of the Internet Most needed in locations where NAT use is likely No pre-existing relationship required No PKI-verifiable client cert, no password, no account No flaming hoops to jump through No VPN, no special client, no plugin, etc.

7. Previous solutions But Jim, aren’t there

8. RFC 4953:“Defending TCP Against Spoofing Attacks” Lots of good discussion and background, but: “Note that Network Address Translators (NATs) and other middleboxes complicate the design and deployment of techniques to defeat spoofing attacks. Devices such as these, that modify IP and/or TCP headers in-transit, generate traffic equivalent to a spoofing attack, and thus should be inhibited by antispoofing mechanisms. Details of these middlebox-related problems are out of scope for this document[…]” [emphasis added] (Section 6, “Security Considerations”, p. 23) Translation: treat NAT like a spoof attack Directed at network operators, not enlightened users Spoofing is most dangerous where NAT is common!

9. IPSec Too much overhead Crypto is easy, ID management is annoying Requires pre-existing relationship Shared secret or shared CA Too big a scope Encrypts ALL IP traffic between endpoints Breaks NAT in the server->client direction e.g. AOL proxy – 1 IP, multiple remote endpoints Will IPsec tunnel capture all traffic back to that IP?

10. IPSec AH Provides auth  Oops, NAT breaks it  Requires pre-existing relationship All the setup of ESP, ½ the value Rumor is it’s going away If it was ever here at all…

11. BTNS (anonymous IPSec) “Better-Than-Nothing Security” Non-authenticated IPSec Ephemeral but assured association  StillIPSec L3 – Same problems w/ NAT 

12. DNSSEC? Good to validate server ID Apparently good to sign emails Can it work with client behind NAT? ID still tied to address/hostname Can a client validate its ID from behind NAPT? Especially a dynamic IP address?

13. SSL? Closer to being the solution: No shared setup (other than signed server cert) Encryption implies ID continuity Only the endpoints have the session key L7 protocol Can be undermined at L2/L3/L4 e.g. Re-binding attack Can’t spoof cert (go with me on this one) Can still inject RST

14. SSL VPN (L3 over L7) Beautifully complicated L3 tunnel through single L7 connection Waaaaay outside this scope User must manually start / install software “Jump through a flaming hoop” Pre-existing relationship required

15. SSH Port Forwarding? Could be done… Would require different port? Non-transparent to application/user SSH really really wants to do user auth Implies pre-shared association Full encryption: overkill?

16. TOR Solves exactly the opposite problem Encryption is implicit ID continuity Still open to L4 control channel attacks

17. TCP-MD5 / TCP-AO Designed to solve this problem  Designed to solve this problem for BGP Requires pre-existing relationship / PSK Doesn’t survive NAT  A draft exists to cover this case draft-touch-tcp-ao-nat-01 Still requires pre-existing relationship

18. The Fossil Record Skeeter and Bubba, FTP Software, 1991 “Levy, Kastenholz and Knowles realized that they couldimprove the security of TCP by putting a Diffie-Hellman key agreement step directly into TCP’s three-way handshake. […and] encrypt all future communications[…] “The project was abandoned for two reasons. First, an engineer at FTP thought that it would be wasteful to have computers calculate large prime numbers for every TCP connection[…] Second[…] it was susceptible to the man-in-the-middle attack.” Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable by Simson L. Garfinkel (Ph.D thesis, 2005) Section 6.1 (p. 201) [emphasis and format added]

19. New Design Is it time for a

20. Scope, revisited: Auth? Authentication: not necessary! Actual auth can happen in L7 RFC 4953 Section 5.5 p. 22 (TCP spoofing) It is sufficient to authenticate the other party as "a party you have exchanged packets with", rather than establishing their trusted identity ("Bill" vs. "Bob")

21. Scope, revisited: Crypto? Encryption: not necessary? Signing is sufficient to assure sender ID Encryption can be done at L7 Anything sensitive should of course be encrypted RFC 4953 Section 5.5 p. 22 “Only the IP header is fundamentally in question, so securing the entire packet […] is computational overkill.”

22. Scope,revisted: WhichOSI Layer? RFC 4953 likes L3 (sections 5.1, 5.2) Establish ID once for all L4 connections NAPT creates multiple hosts per L3 address L4 is lowest layer with unique endpoints Control channels at L3 & L4 L3: ICMP: common practice is to firewall L4: RST, ACK, etc.: necessary part of conv. L4 looks like best fit: extend TCP

23. Scope, revisited: Where in TCP? Injecting data will change TCP seq/ack Too hard to track, work to re-write TCP option Control field at same layer as control channel “Easy” to add, verify Similar to TCP-MD5 and TCP-AO Either way, will affect checksum Easy to calculate Hardware offload common

24. Scope, revisited: Signature? Both endpoints must be able to validate packets from other endpoint Only need 1 RST in either direction to kill stream 2 options: Shared secret w/ symmetric key Public/Private signature Symmetric is faster Must not expose key: requires setup Can setup be accomplished during TCP setup?

25. Symmetric solution: DH Diffie Hellman solves this exact problem Secure negotiation of shared secret key Doesn’t provide auth Public key != Identity (vs. SSL cert) Subject to MITM Requires attacker to proxy TCP SYN exchange Bi-directional spoofing

26. Hybrid solution Common practice (IPSec, SSL, etc.) Use RSA/DSA signature validation DH doesn’t need protection Can sign DH pub key is validate RSA/DSA key Valid key = assured identity True “Digital Signature” Packet includes signature with signed data No advance association required

28. Client-side anonymous ID persistence Client RSA/DSA public key is relatively unique Not listed in verifiable PKI “Randomly” generated Server can cache client public key Becomes ID-equivalent Useful for continuity of ID?

29. Issues Adding TCP option takes space Solution: reduce MSS Must be done in SYN Introduce inefficiency if TCP hash not used Checking every packet adds process overhead Can streamline through clever iptables rules

30. Proof-of-Concept #FAIL Release delayed due to some core issues  DH library issues keygen ran for many hours without completion Bad implications for performance Really neediptables custom rules Use 4-tuple for DH secret lookup Current PoC uses ipq (only 1 handler) Should use NFQUEUE (multiple handlers)

31. Proof-of-Concept Implementation Use iptables QUEUE target for userspace processing of packets http://michael.toren.net/slides/ipqueue/ Perl script to manipulate packets Packet manipulation with NetPacket (NOT Net::Packet) Custom code for TCP options NetPacket doesn’t handle TCP options well

32. POC – Setup SYN Outbound add DH Iptables: outbound SYN Inbound detect DH, calculate secret, add iptablesrule Iptables: detect TCP option SYN/ACK Inbound detect DH, calculate secret, add iptables rule Iptables: detect TCP option Outbound add DH Iptables: specific (4-tuple)rule

33. POC - established Iptables rule for 4-tuple (src/dst for IP/TCP) Outbound: add TCP option Hash TCP payload using DH shared secret Inbound: verify Hash TCP payload using DH shared secret Compare to hash in inbound packet Fail -> Drop

34. POC – tear-down RST: simple Sign & send, then decommission iptables rule FIN: more complicated 1st FIN: remember, sign & send 2nd FIN: remember, sign & send ACK: sign & send & decommission iptables rule

35. “The Dream” Design is incrementally deployable Add to individual machines, not all-at-once Design is backwards compatible Won’t prevent other services from running “Minor performance impact” Clever use of iptables limits computations to protected sessions

36. The Real Dream Assured ID with DNSSEC NAT “should” go away after IPv6 Maybe this tool will be useful until then

37. Questions? Jim MacLeod Twitter: @shewfig Blog: shewfig.blogspot.com