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

[Alan Robertson]

Crispin Cowan wrote:
> 
> Alan Robertson wrote:
> 
> > 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".
> 
> This method is remarkably weak.  If you have 4 crypto methods, that's effectively a 2-bit
> extension to key length.  The main strength of a protocol supporting multiple algorithms is
> that if a crypto weakness in one of the hash or cipher algorithms, then administrators can
> quickly select an alternate cipher, rather than having to wait for a patch to the
> implementation.

It's certainly no weaker than one method. Also, in the case of a sophisticated
site, they don't necessarily know how many methods the site has at their
disposal.   I didn't say this, but the main reason why we put more than one in
was to allow a site to make the implementation cost versus strength tradeoff
themselves, rather than us making it for them.  Avoiding arguments is always a
good idea :-).  Also, if someone needs a different method, they don't have to
fork the code to do it.  It's simply a better design, which we needed it for
smooth key transitions anyway.

> >         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.
> 
> Is there anything to prevent an attacker from sniffing such a packet to snarf the new key
> 2?  This re-keying protocol is a subset of the general problem of key distribution, which
> is never easy.

Rekeying isn't something we address yet.  This is the first release with any
protection at all.  Since we only handle small clusters (2 nodes) at this point,
it is not unreasonable to say "take this floppy...", and go from there.  An
administrator could also use ssh, etc.  As you said, it's never easy.  Secure
key distribution tends to involve encryption, which is heavily regulated here in
the US.  Mitja is outside the US, and he could do this... But, I couldn't
distribute it from here.  Not the right place to start for a project which isn't
primarily a crypto project.

As we add nodes, and work with LVS clusters (with hundreds of nodes), this needs
to be solved.  Applications are being accepted...		;-)

	-- Alan Robertson
	   alanr@bell-labs.com