linux-kernel - Re: [PATCH v3 4/4] nvme: Allow reauth from sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKmqyKOTqDovbBt3ThxAO+nmBkp0Zm=cuFa-M1f0t5qRyv+49Q@mail.gmail.com>
Date: Wed, 19 Nov 2025 20:21:19 +1000
From: Alistair Francis <alistair23@...il.com>
To: Hannes Reinecke <hare@...e.de>
Cc: kbusch@...nel.org, axboe@...nel.dk, hch@....de, sagi@...mberg.me, 
	kch@...dia.com, linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	Alistair Francis <alistair.francis@....com>
Subject: Re: [PATCH v3 4/4] nvme: Allow reauth from sysfs

On Wed, Nov 19, 2025 at 5:45 PM Hannes Reinecke <hare@...e.de> wrote:
>
> On 11/19/25 01:24, Alistair Francis wrote:
> > On Tue, Nov 18, 2025 at 9:50 PM Hannes Reinecke <hare@...e.de> wrote:
> >>
> >> On 11/18/25 01:52, Alistair Francis wrote:
> >>> On Fri, Nov 14, 2025 at 5:15 PM Hannes Reinecke <hare@...e.de> wrote:
> [ .. ]>>>>
> >>>> Hmm.
> >>>> Now we are just running (re-) authentication, but that does
> >>>> not affect the TLS connection (which continues to use the
> >>>> original key). So you would need to reset the connection
> >>>> here to re-establish a new TLS connection.
> >>>
> >>> Is the connection supposed to be reset? I don't see any mention of
> >>> that in the spec
> >>>
> >> Yeah, that's a bit hard to read (as usual).
> >> The base spec just claims (Fig. 733, Secure Channel Protocol Identifiers):
> >>
> >> 03h: This {PSK, PSK Identity} pair replaces the {PSK, PSK Identity}
> >>     pair that was used to set up the TLS secure channel over which the
> >>     authentication transaction is performed.
> >>
> >> So from that your implementation is correct, as it just replaces the
> >> PSK (without actually using them). However, the TCP spec clarifies
> >> (section 3.6.1.4: PSK Use):
> >>
> >> Once the TLS secure channel for the Admin Queue of an association
> >> has been set up with a generated {PSK, PSK Identity} pair, that
> >> generated {PSK, PSK Identity} pair should be replaced periodically
> >> (e.g., every hour) or on demand by performing a reauthentication
> >> with the SC_C field in the AUTH_Negotiate message set to REPLACETLSPSK
> >> (refer to the AUTH_Negotiate Message section of the NVM Express
> >> Base Specification) over the Admin Queue of that association. The most
> >> recently generated PSK, if any, is the generated PSK associated with
> >> that Admin Queue.
> >
> > Yeah, to me "associated with" doesn't necessarily mean that we reset
> > the connection to use the new PSK.
> >
> But then why would we want to replace the PSK if it's not used?Which
> would be completely pointless for secure concatenation, as
> for _any_ connection establishment a new PSK will be generated.
>
> And I've checked with FMDS, the intention really was that REPLACETLSPSK
> should result in the new PSK to be _used_ for existing connections.

Ok, so tear down the connection and reconnect. I'll work on adding that

>
> There's now a bug for this:
> https://bugzilla.nvmexpress.org/show_bug.cgi?id=638
> and it should be addressed with an ECN.
>
> >>
> >> And the only way to associate a PSK with the admin queue is to use
> >> it for the TLS encryption, ie re-run the TLS handshake.
> >>
> >> Or indeed use the KeyUpdate mechanism.
> >
> > This is the part that I think is weird.
> >
> > If we do need to use the new PSK, once a host issues a REPLACETLSPSK
> > we have to tear down and restart the TLS connection. Which seems
> > really clunky and the spec doesn't seem to mention that at all.
> >
> > If the host wants to replace the TLS keys it can just issue a
> > KeyUpdate, which doesn't involve tearing down the entire connection.
> > So do we actually need to reset the TLS connection after a
> > REPLACETLSPSK?
> >
> Oh, I fully agree. KeyUpdate would be the way to go to get a seamless
> PSK replacement. But not all implementations do it (currently not even
> the linux kernel :-), so in the absence of that we have to reset the
> queue to start a new TLS handshake.

Urgh, let's get everyone supporting KeyUpdate then :)

Alistair

>
> Cheers,Hannes
> --
> Dr. Hannes Reinecke                  Kernel Storage Architect
> hare@...e.de                                +49 911 74053 688
> SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
> HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich