Re: [Nbd] nbd-server working easily in cygwin in XP

[Wouter Verhelst <w@...112...>]

On Tue, Aug 12, 2008 at 05:29:51PM -0300, Wouter Verhelst wrote:
> On Tue, Aug 12, 2008 at 11:10:14AM -0700, qm <Brad Allen wrote:
> >     couldn't as easily steal or modify runnable data.  To make it
> >     really secure, nbd-server ought to have a password settable in the
> >     config file that nbd-client must use, which it requires upon
> >     negotiation.
> 
> I completely agree. It's been on my TODO list for a few years (with
> dreams of adding Kerberos support, too), but just hasn't happened yet.
> There're a few reasons for that:
> - First, I want to keep nbd-client as small as possible, so that it'll
>   fit on embedded devices and in initrds and such; so using a (possibly
>   huge) library to implement password authentication is out, unless it
>   can optionally be disabled; this rules out things like SASL and
>   Kerberos if they're the only thing we're going to use.
> - Second, I do /not/ want to send passwords across the wire in the clear
>   in any case. Doing this will only provide a false sense of security,
>   and I don't want to do that in any case.
> - Third, so far I just haven't had the time to properly work out a
>   solution that satisfies both of the above constraints.

Actually, come to think about it, one advantage of being at a conference
like Debconf is that you can ask people around you to help
brainstorming.

What we came up with is this:
- Server sends a random number as a way to challenge the client for a
  password
- Client constructs something based on the IP address, password, and the
  random number the server sent, pumps it through a secure hash
  algorithm, and sends that back.
- Server constructs the same thing and pumps it through the same
  algorithm. If the output matches, we're authenticated; if it doesn't
  match, we're not.

Doing a checksum isn't usually an insanely expensive operation, and can
probably be done in a reasonably small amount of code, thereby not
enlarging nbd-client too much. Anyone writing this will have to learn
such an algorithm first, obviously; or alternatively, if we can find a
small library somewhere that will do such checksums _only_, we may
consider including that as a build requirement. I'm specifically not
considering openssl here, which takes about half a meg and may be too
much for embedded things or initramfses on memory-constrained systems.

This principle is reasonably future-proof; if the particular checksum
protocol we choose ever goes the way of MD5 (which people are now able
to construct a collision for in minutes on a laptop, according to
wikipedia), we can replace the checksum algorithm but keep the same
principle.

The IP address requirement is included as a simple MITM protection. Of
course this doesn't make NBD safe for eavesdroppers (no encryption, so
anyone with a sniffer between client and server can map out the entire
contents of the block device, given time), but at the very least it will
prevent unauthenticated access.

Thoughts, anyone?

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22