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

[Hannes Reinecke]

On 11/19/25 01:24, Alistair Francis wrote:
> On Tue, Nov 18, 2025 at 9:50 PM Hannes Reinecke <hare@xxxxxxx> wrote:
> > On 11/18/25 01:52, Alistair Francis wrote:
> > > On Fri, Nov 14, 2025 at 5:15 PM Hannes Reinecke <hare@xxxxxxx> 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.

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.

Cheers,Hannes
--
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@xxxxxxx                                +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