Re: [PATCH] nvme-auth: Hash DH shared secret to create session key

Hannes Reinecke
2026-03-12T06:57:54Z

On 3/11/26 17:44, Chris Leech wrote:
> On Wed, Mar 11, 2026 at 09:17:49PM +0530, Martin George wrote:
>> On Tue, 2026-03-10 at 18:21 -0700, Chris Leech wrote:
>>> When using secure channel concatenation with bidirectional
>>> authentication, this results in hashing the DH value three times:
>>> twice
>>> for augmented challenge calculations and once during PSK generation.
>>>
>>
>> But secure channel concatenation is supported only with unidirectional
>> auth and not really with bidirectional auth, isn't it? As per NVMe base
>> spec 2.1, section 8.3.4.5.9 Generated PSK for TLS:
>>
>> "The host may request secure channel concatenation with the TLS
>> protocol by setting the SC_C field in the AUTH_Negotiate message to
>> NEWTLSPSK while performing only unidirectional authentication. In this
>> case the host shall still send a challenge value C2 to the controller
>> and clear the sequence number S2 to 0h to indicate that controller
>> authentication is not requested."
>
> I believe this is specifying how secure channel concatenation can work
> "while performing only unidirectional authentication", not that it's
> only allowed with unidirectional. It's a special case where C2 is sent
> in Reply without expecting an R2 value in Success1 or to send Success2.
>
> It would be counterproductive to forbid the host from authenticating the
> controller when a secure channel is desired.
>

Yeah, I do agree. After careful re-reading I agree with Chris; the
quoted sentence is at the end of the section describing secure
concatenation, so it really is a clarification how to handle secure
concatenation if unidirectional authentication is employed.

We might go to fmds for clarification, though.

Cheers,

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