public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Stefan Sterz" <s.sterz@proxmox.com>
To: "Proxmox Backup Server development discussion"
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup 12/12] auth: us ec keys as auth keys
Date: Fri, 23 Feb 2024 10:26:39 +0100	[thread overview]
Message-ID: <CZCCNF53OHUV.1854W09HKN1VK@proxmox.com> (raw)
In-Reply-To: <736a3096-d3dc-40ca-850a-e7f85a155d7e@proxmox.com>

On Mon Feb 19, 2024 at 8:10 PM CET, Max Carrara wrote:
> On 2/15/24 16:20, Stefan Sterz wrote:
> > this commit moves new installations from our default rsa keys toward
> > smaller and more efficient ec keys. this uses the `PrivateKey` and
> > `PublicKey` structs from proxmox-auth-api to handle generating the
> > keys.
> >
> > this means we can move aways from using openssl directly in the
> > auth_helpers and instead rely on the implementation in
> > `proxmox-auth-api`. thus, further unifying key handling in
> > `proxmox-auth-api`. this should make it easier to switch keys in the
> > future if necessary.
> >
> > Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
> > ---
> > note that this breaks the following scenario:
> >
> > - a user installs pbs from a version after this patch was packaged
> > - proxmox-backup then creates a new ed25519 authkey
> > - the user manually forces a downgrade
> >
> > proxmox-backup-api and proxmox-backup-proxy will now fail to start as
> > they cannot read the, from their perspective, malformed authkey.
>
> Can we not ensure we remain forward-compatible here, too? I acknowledge
> that we probably shouldn't support this kind of scenario, but if we
> were to add support for ed25519 keys now (while continuing to use RSA)
> we wouldn't ever run into problems in that regard.
>
> Not sure if it actually makes sense to remain forward-compatible here,
> though.
>

well yeah we could do something like this, but where to we draw the
boundary? we don't support downgrades so which version should introduce
being able to load and handle ed25519 keys and which version should then
start generating such keys?

i can separate out the loading and generating part in the next version
of this series though, than we can apply them as we see fit.

also two notes:

1) such a downgrade scenario can easily be fixed by the admin by removing
   the authkey. proxmox-backup-api will then just generate a new one next
   time it is started with the old rsa format.

2) existing installations aren't impacted at all, as no new authkey will
   generated if one already exists. there is no mechanism that checks if
   the key is old/insecure/in-efficient or should be upgrade for other
   reasons. as long as a key exists, no new key is generated. pbs also
   lacks key-roll-over/key-rotation afaict, so yeah, once and authkey is
   generated, it is never modified by pbs itself.

-- >8 snip 8< --




      reply	other threads:[~2024-02-23  9:26 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 15:19 [pbs-devel] [PATCH proxmox{, -backup} 00/12] authentication cleanup and Stefan Sterz
2024-02-15 15:19 ` [pbs-devel] [PATCH proxmox 01/12] auth-api: move signing into the private key Stefan Sterz
2024-02-26 20:22   ` Esi Y
2024-02-27  9:12     ` Stefan Sterz
2024-02-27 18:13       ` Esi Y
2024-02-29 16:07         ` Stefan Sterz
2024-02-15 15:19 ` [pbs-devel] [PATCH proxmox 02/12] auth-api: move to Ed25519 signatures Stefan Sterz
2024-02-15 15:19 ` [pbs-devel] [PATCH proxmox 03/12] auth-api: add ability to use hmac singing in keyring Stefan Sterz
2024-02-15 15:19 ` [pbs-devel] [PATCH proxmox 04/12] auth-api: move to hmac signing for csrf tokens Stefan Sterz
2024-02-19 16:02   ` Max Carrara
2024-02-20 12:54     ` Max Carrara
2024-02-23  9:26       ` Stefan Sterz
2024-02-23 10:48         ` Thomas Lamprecht
2024-02-23 10:52           ` Stefan Sterz
2024-02-23 13:06         ` Wolfgang Bumiller
2024-02-15 15:19 ` [pbs-devel] [PATCH proxmox 05/12] sys: crypt: move to yescrypt for password hashing Stefan Sterz
2024-02-15 15:19 ` [pbs-devel] [PATCH proxmox 06/12] sys: crypt: use constant time comparison for password verification Stefan Sterz
2024-02-19 16:11   ` Max Carrara
2024-02-23  9:26     ` Stefan Sterz
2024-02-15 15:19 ` [pbs-devel] [PATCH proxmox 07/12] sys: crypt: add helper to allow upgrading hashes Stefan Sterz
2024-02-19 18:50   ` Max Carrara
2024-02-23  9:26     ` Stefan Sterz
2024-02-15 15:19 ` [pbs-devel] [PATCH proxmox 08/12] auth-api: fix types `compilefail` test Stefan Sterz
2024-02-15 15:19 ` [pbs-devel] [PATCH proxmox-backup 09/12] auth: move to hmac keys for csrf tokens Stefan Sterz
2024-02-19 18:55   ` Max Carrara
2024-02-23  9:26     ` Stefan Sterz
2024-02-15 15:19 ` [pbs-devel] [PATCH proxmox-backup 10/12] auth: upgrade hashes on user log in Stefan Sterz
2024-02-19 18:58   ` Max Carrara
2024-02-23  9:26     ` Stefan Sterz
2024-02-15 15:20 ` [pbs-devel] [PATCH proxmox-backup 11/12] auth/manager: add manager command to upgrade hashes Stefan Sterz
2024-02-19 19:06   ` Max Carrara
2024-02-23  9:26     ` Stefan Sterz
2024-02-15 15:20 ` [pbs-devel] [PATCH proxmox-backup 12/12] auth: us ec keys as auth keys Stefan Sterz
2024-02-19 19:10   ` Max Carrara
2024-02-23  9:26     ` Stefan Sterz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CZCCNF53OHUV.1854W09HKN1VK@proxmox.com \
    --to=s.sterz@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal