| Message ID | 20210810124230.12161-1-hare@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | nvme: In-band authentication support | expand |
> 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? 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?
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