[Linux-ha-dev] Heartbeat authentication [was Re: Heartbeat 0.45 experiences]

[Alan Robertson]

Crispin Cowan wrote:
> 
> Alan Robertson wrote:
> 
> > The authentication was added to prevent an outside computer from being
> > accepted as a cluster member by the cluster itself, and thereby obtaining the
> > rights and privileges that go with that.  It is believed that it will also
> > make it somewhat more difficult for an outside computer to disrupt
> > intracluster communications.
> 
> Thanks!  That does clarify the intent.
> 
> > I haven't been worried about things I didn't create (like old holes).
> 
> A very reasonable philosophy for a project who's main aim is not security.  All too
> many projects don't even do that :-(

Linux boxes are like targets with big bull's-eye's on them.  The current cluster
protocol is really trusting.  A really bad combination if you don't have secure
communications.  Any box worth protecting with HA is a box valuable enough to
crack.
 
> So it's my understanding that the nodes keep sending each other "I know a secret, and
> here's a hash of the secret" packets, and the "secret" in question is a key shared
> among all the nodes.  There's something interesting going on with the way you're using
> crypto hashes, but I haven't thought about it very carefully.

The packets are mostly (but not exclusively) heartbeat packets.  Each one of
them is signed with the crypto hash, so that we can tell that they are
authentic, in the manner you described.  If you crank up the debug (send it
about 5 SIGUSR1's), you can see each packet in the logs, including the
authentication fields.  SIGUSR2's lower the debug level.

A nice thing about what we're doing is that we allow several different methods
and different keys.  The packets we send on the wire don't indicate directly
which hash method we're using (there's no fixed mapping between the numbers and
the methods), so it seems like it would make it a little more difficult to
crack, especially if you padded out the keys to all look the same in format. 
Since this is open source code, you can easily add new ones, or mangle ones you
have for "security through obscurity".

The purpose of allowing several keys in the authkeys file is to make it possible
to smoothly switch to a new key in a continuously running system.

Assume you initially are authenticating on key 1:

	You distribute out a new authkeys file to each machine which has key 1 and
		a new key 2 both in it.  The auth statement at the top still says
		auth 1. Go to next step when this one is done on all nodes.

	You can now distribute a new authkeys file which has the same keys in it,
		but says "auth 2" at the top.
		Go to next step when this one is done on all nodes.

	Distribute a new authkeys file which has only key 2 in it.
		The first key is now repudiated, and is no longer valid.

None of this disrupts the cluster at all.  Modify the authkeys file, and send
heartbeat a SIGHUP.  New authkeys are in now in effect.

Neal says this is somewhat similar to what NTP does.  Myself, just think it's
pretty cool, and it's definitely needed :-)

We also got plain checksums (for physically secure networks) for "free" ;-)

Neal did the research to select the methods for security, freedom from patents
and export restrictions, and Mitja Sarp did all the hard work to make it work. 
I acted as architect, and made minor changes in the way the pieces were glued
together.  A pretty good team effort!

	Special thanks to Neal and Mitja!

	-- Alan Robertson
	   alanr@bell-labs.com