[Libguestfs] [PATCH nbdkit] tls: Implement Pre-Shared Keys (PSK) authentication.

[Nir Soffer]

On Thu, Jun 28, 2018 at 6:56 PM Daniel P. Berrangé <berrange at redhat.com>
wrote:

> On Thu, Jun 28, 2018 at 10:18:25AM -0500, Eric Blake wrote:
> > On 06/25/2018 12:01 PM, Richard W.M. Jones wrote:
> > > ---
> > >   docs/nbdkit.pod.in |  45 +++++++++--
> > >   src/crypto.c       | 234
> +++++++++++++++++++++++++++++++++++++----------------
> > >   src/internal.h     |   1 +
> > >   src/main.c         |   8 +-
> > >   4 files changed, 210 insertions(+), 78 deletions(-)
> > >
> >
> > > +Create a PSK file containing one or more C<username:key> pairs.  It is
> > > +easiest to use L<psktool(1)> for this:
> > > +
> > > + psktool -u rich -p /tmp/psk
> > > +
> > > +The PSK file contains the hex-encoded random keys in plaintext.  Any
> > > +client which can read this file will be able to connect to the server.
> >
> > If I'm understanding correctly, it's also possible for a server to
> create a
> > file that supports multiple users:
> >
> > c1:1234
> > c2:2345
> >
> > but then hand out a smaller file to client c1 that contains only the
> c2:1234
> > line, and another small file to client c2, and then a single server can
> not
> > only accept multiple clients but also distinguish which client
> connected. Is
> > there any reason for nbdkit as a server to additionally limit which
> > resources are served depending on which client connected?
> >
> > But that's probably overkill for now; as it's just as easy to point
> nbdkit
> > to the smaller file in the first place, and since right now nbdkit
> serves up
> > at most one file, provided the client can connect in the first place (it
> > would matter more for something like nbd-server, which has an init file
> that
> > specifies multiple resources served by a single server, and therefore
> might
> > want per-user restrictions on those resources).
>
> I could see a situation where a host has a single file of keys + users used
> for all NBD servers, and then whitelists specific user names per instance.
> Not a blocker, but conceptually relevant. When I add the authorization work
> to QEMU I'd intend to use that to authorize the client username.


I don't think we should make it easy to have a static files with many keys
and
user names. Shared key should be used exactly once, for single operation.
This means that you cannot loose the key and you don't need to manage it.

It would be best if we could pass the key to without writing it to actual
file
so we don't have to clean it up later.

Nir


>
>
> Regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
> _______________________________________________
> Libguestfs mailing list
> Libguestfs at redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180629/f07742d3/attachment.htm>