Message-ID: <60e86d7c-f926-4b75-96eb-dc8fd8a06ee8@suse.de>
Date: Wed, 19 Nov 2025 08:45:01 +0100
From: Hannes Reinecke <hare@...e.de>
To: Alistair Francis <alistair23@...il.com>
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 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.

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@...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

Powered by blists - more mailing lists