Challenge-response port knocking for TCP

[Bill Stewart]

At 11:21 PM 3/19/2004, Thomas Shaddack wrote:
>The idea of advertising opportunistic crypto presence in TCP/SYN inspired
>me to another one: authenticated connection handshake for TCP protocol.
>
>Scenario: Application listening on port P of server S, only for
>authenticated users.
>
>Unknown user sends TCP/SYN to S:P, gets back TCP/RST, with challenge in
>MD5 field of TCP options. The user doesn't support this scheme, so
>considers the port closed.
>
>Unknown-now known user sends TCP/SYN, gets back TCP/RST with the
>challenge, sends another TCP/SYN, this time with calculated response using
>a shared secret, again in TCP MD5 option field, gets back TCP/SYNACK.


Firewalls may munge the TCP headers, and if you're just protecting the 
session setup,
you still need to worry about eavesdroppers and session hijackers.
Also, this doesn't strike me as the right protocol layer to address the 
problem at.


If you want to be secure, either use IPSEC (in which case this isn't that 
necessary),
or else use SSL if you'd rather wrap things in Layer 4.
Alternatively, do the job at Layer 7.