Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCHv2 00/13] nvme: In-band authentication support
To:     Sagi Grimberg <sagi@grimberg.me>, Christoph Hellwig <hch@lst.de>
Cc:     Keith Busch <keith.busch@wdc.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S . Miller" <davem@davemloft.net>,
        linux-nvme@lists.infradead.org, linux-crypto@vger.kernel.org
References: <20210810124230.12161-1-hare@suse.de>
 <5a69187b-cfb1-d09a-87e2-8435e27612a7@grimberg.me>
From:   Hannes Reinecke <hare@suse.de>
Message-ID: <dbf2ca1f-32f6-2aff-da08-d3fd2f977fa5@suse.de>
Date:   Wed, 18 Aug 2021 07:44:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <5a69187b-cfb1-d09a-87e2-8435e27612a7@grimberg.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

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@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer