[Nut-upsdev] Common NUT client auth setup

[Greg Troxel]

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:

> Well, regarding features I propose to pass via some `nutauth.conf` files,
> this is about using settings that are already available in (mostly)
> `upsmon.conf` for the client side, varying based on whether the build uses
> an NSS or OpenSSL backend.
> This partially mirrors the server side settings for `upsd.conf`.
>
> Ability for client auth via certs is in the tree (for NSS at least) for a
> long time, but only upsmon had the endpoints attached to configuration
> options and calls made into `libupsclient`.
>
> I believe it originated from the fact that NUT reads like those with `upsc`
> are inherently anonymous (maybe something can/should be done about that
> too/instead), so sites that want to use SSL to protect their engineering
> network from any sort of revealing their hardware and its state to
> unpermitted clients, would use CERTVERIFY to only allow the channel for
> whatever use (including auth/anon in the layer above that, before it comes
> to that) to programs that have the correct client cert. Probably this
> implies some sort of private/corporate CA.

I think we should step back and ask what the requirement is, and then
think about how to meet it and how that solution would go over with
users.

I can see a "want to restrict commands to authorized users".  One can do
that with

  client certs
  username/password
  SASL in general, perhaps openidconnect
  kerberos/gssapi
  etc.

If you look at email, I am aware of very little use of client certs.


I hink it's a huge and incorrect leap to go from "want to control access
to upsc" to "we should use client certs".

> Program-specific setup of crypto stuff is common in the web server world I
> had a lot of experience with, whether it is Apache, or Nginx, or one of
> many Java web-app servers. These typically configure the trusted credential
> locations (cert with public key and CA chain, private key, possibly the
> generally-trusted corporate CA to issue requests to nearby servers) and do
> not use a system-wide location (or at best fall back to using it if the
> dedicated store lacks some info). It is similar with CI systems that can
> store such credentials and let them be used per remote system they use (and
> trust) for a particular job; a neighboring job or a different run of this
> one should not necessarily have access to that system if it is not allowed
> to use the credential (e.g. to avoid tests aimed at one SUT to bombard an
> unrelated system by mistake).

A good argument for credentials of some sort, not for client certs in
particular.

> I think the NUT approach is somewhat modeled after those examples, like a
> web server and potentially trusted/trusting clients constrained to a small
> population with access given on a need-to-know basis (perhaps NOT trusting
> servers/clients from corporate-wide or world-wide public CA is the point of
> an engineering network setup with its own CA for equipment like networked
> UPSes, NMCs, ILOMs and stuff like that). I'm not a regular sysadmin
> anymore, but back in the days I did set up eng networks like that for
> dayjob and its customers, so would have been a prime user for this feature.

Wanting to use PKI but only trust your own CI is a particular approach
that some would want.  That's fine.  But it's a leap to think that
anyone who wants any access control wants to run a private CA.
 
> I agree that building a binary with multiple SSL backend support is not
> likely to find real users, other than CI runners that can test all those
> code paths in one build... which in itself is not too bad a reason, would
> probably shave a few hours off the build matrix :)

except that it wouldn't be testing what users actually build and run.