sysfs tls_configured_key naming?

[Hannes Reinecke]

On 10/17/24 12:54, Daniel Wagner wrote:
> f5eb7397471b ("nvme-sysfs: add 'tls_configured_key' sysfs attribute")
> claims that the --tls_key is expecting a 'Configured PSK'. That is not
> correct. It expects a 'Derived TLS PSK'. That means user space has to do
> the whole key transformation as described in Figure 21: {TLS PSK, TLS
> Identity, Hash} Tuple Derivation in TCP Transport Specification,
> Revision 1.1.
> 
Not necessarily. The spec indicates two methods:

 > Each NVMe/TCP entity shall support:
 > * transforming the configured PSK into a retained PSK before it is
 >   stored by the NVMe/TCP entity for repeated use with another
 >   NVMe/TCP entity; and
 > * using the configured PSK as a retained PSK.

>  From a quick look at the concatenation patches and based on the spec,
> tls_configured_key will never hold the 'Configured PSK'. I think we
> should use a better name for this sysfs attribute. I suppose it should
> be named 'tls_generated_psk'?
> 
No. The 'generated' PSK (in the current wording of the TLS concatenation
patches) is the PSK generated internally during TLS concatenation.
And, curiously, the only one which will _never_ be presented in the
'tls_configured_key' attribute.

> BTW, that means also for the second tuple derivation flow (where we
> start with the 'Configured PSK'), the keystore doesn't contain a
> 'Retained PSK'. I think I need to do some more reviewing and cleanups in
> libnvme to get it matching with the naming scheme of the spec in line.

There actually is an easy way out of it; the TLS interchange format is
NVMeTLSkey-1:xx:<Base64 encoded string>:
where 'xx' can be either '00' (indicating no transformation should be
done, ie the second bulled point above), or '01'/'02' (indicating which
hash function to use for the key derivation).

So in our internal parlance, the key data in 'tls_configured_key' can 
only be used as 'NVMeTLSKey-1:00:<base64 encoded string>' format, to
avoid any addtional transformation.

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