The weakness of doing authentication over a side channel

November 5, 2014

Yesterday I mentioned our method of authenticating NFS client hosts; fundamentally it operates by every so often verifying that the client host knows a secret. Suppose that we had a slightly improved version of this, where the NFS fileserver holds an authenticated TCP connection open with the client and periodically exchanges authenticated and encrypted packets with it; the simple version of this would just be a SSH connection with SSH level keepalives. Is this a reasonably secure system or is it attackable?

(A system without a continuous authentication connection is trivially attackable; get the real client to authenticate once, force it off the network, and replace it with your imposter client.)

Unfortunately, yes it is. Take your attack host with two network interfaces and insert it as a bridge between a valid client and the client's normal network. Now set your host to pass SSH traffic through the bridge to the valid client (and back out) but to intercept and generate its own NFS traffic. We will now authenticate the valid client but take NFS requests from your imposter client, and the authentication channel will stay perfectly live while you're doing this.

As far as I can tell this is a fundamental weakness of doing authentication over a side channel instead of the channel that your main communication is flowing over. If the authentication is not strongly connected with the actual real conversation, an attacker can peel the two apart and pass the authentication to a valid client while handling the real conversation itself. For full security, the authentication should be an intrinsic and inseparable part of the main communication.

(There are hacks you can try if you're stuck with separate channels, like having the client observe signs of the main protocol in action and report them back over the authentication channel. If this doesn't match the server's view of the client's activity, something's up.)

PS: I'm sure this is well known in the security and protocol design community. I'm writing it down for myself, because I want to remember the logic of this after I worked it out in my head.


Comments on this page:

By dozzie at 2014-11-05 02:43:27:

Wrong. You don't need the communication and authentication over the same channel. IPsec uses AH/ESP to transfer data, and ISAKMP to negotiate AH/ESP tunnels, including session keys.

What you need is to use the ephemeral secret established in authentication phase to protect the integrity of transmission. Since the secret is only known to the protocol parties, nobody can spoof the communication.

By Ewen McNeill at 2014-11-05 04:05:40:

Re: dozzie's comment, technically what IPSec is doing is authenticating each message, in the same channel (ie, in the ipsec frames, not in the IKE side channel). The mechanism that they are authenticated is by using an ephemeral shared secret negotiated over a side channel -- but the rejection of "not valid" messages happens precisely because the authentication is carried in-band (either via an AH header, or via encryption in ESP mode resulting in a sane decryption -- eg, sane packet headers at the end); there's nothing else other than those in-band additional bits saying they're valid.

Re the main post, it really depends on what you're trying to authenticate. Traditional NFS stops at about the point of "is on the network with an expected IP address, and something running as root" -- if so, trust it completely. Its threat model is... primitive compared with modern networks. It sounds like you want to authenticate requests are coming from a trusted process on that host, which is much harder to achieve (and as you note, nearly impossible out of band). Avoiding falling victim to an active man in the middle is even harder (without, eg, end to end encryption with a key obtained via a mechanism the MITM cannot determine -- a solution it sounds like you'd prefer to avoid).

Ewen

Written on 05 November 2014.
« Hassles with getting our NFS mount authentication working on Linux
(Probably) Why Bash imports functions from the environment »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Nov 5 01:04:27 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.