On 8/17/21 11:21 PM, Sagi Grimberg wrote:
Hi all,
recent updates to the NVMe spec have added definitions for in-band
authentication, and seeing that it provides some real benefit
especially for NVMe-TCP here's an attempt to implement it.
Tricky bit here is that the specification orients itself on TLS 1.3,
but supports only the FFDHE groups. Which of course the kernel doesn't
support. I've been able to come up with a patch for this, but as this
is my first attempt to fix anything in the crypto area I would invite
people more familiar with these matters to have a look.
Also note that this is just for in-band authentication. Secure
concatenation (ie starting TLS with the negotiated parameters) is not
implemented; one would need to update the kernel TLS implementation
for this, which at this time is beyond scope.
As usual, comments and reviews are welcome.
Hey Hannes,
First, can you also send the nvme-cli/nvmetcli bits as well?
Yes, will be done with the next round.
It first required a larger update to libnvme/nvme-cli to get everything
in order :-)
Second, one thing that is not clear to me here is how this
works with the discovery log page.
If the user issues a discovery log page to establish connections
to the controllers entries, where it picks the appropriate
secret?
In other words, when the user runs connect-all, how does it handle
the secrets based on the content of the discovery log-page?
With the latest nvme-cli update I've implemented a json configuration,
which allows to store configuration on a per-controller basis.
This will be updated to hold the dhchap secrets, and we should be able
to specify individual secrets for each controller.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
