[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 at suse.de> wrote:
>>
>> On 11/18/25 01:52, Alistair Francis wrote:
>>> On Fri, Nov 14, 2025 at 5:15 PM Hannes Reinecke <hare at suse.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.

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 at suse.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