[PATCH 09/11] nvmet: Implement basic In-Band Authentication

[Hannes Reinecke]

On 7/19/21 1:52 PM, Stephan Mueller wrote:
> Am Montag, dem 19.07.2021 um 13:10 +0200 schrieb Hannes Reinecke:
>> On 7/19/21 12:19 PM, Stephan Mueller wrote:
>>> Am Montag, dem 19.07.2021 um 11:57 +0200 schrieb Hannes Reinecke:
>>>> On 7/19/21 10:51 AM, Stephan Mueller wrote:
>>>>> Am Montag, dem 19.07.2021 um 10:15 +0200 schrieb Hannes Reinecke:
>>>>>> On 7/18/21 2:56 PM, Stephan Müller wrote:
>>>>>>> Am Sonntag, 18. Juli 2021, 14:37:34 CEST schrieb Hannes Reinecke:
>>>>>
>>>>>>>> The key is also used when using the ffdhe algorithm.
>>>>>>>> Note: I _think_ that I need to use this key for the ffdhe
>>>>>>>> algorithm,
>>>>>>>> because the implementation I came up with is essentially plain
>>>>>>>> DH
>>>>>>>> with
>>>>>>>> pre-defined 'p', 'q' and 'g' values. But the DH implementation
>>>>>>>> also
>>>>>>>> requires a 'key', and for that I'm using this key here.
>>>>>>>>
>>>>>>>> It might be that I'm completely off, and don't need to use a key
>>>>>>>> for
>>>>>>>> our
>>>>>>>> DH implementation. In that case you are correct.
>>>>>>>> (And that's why I said I'll need a review of the FFDHE
>>>>>>>> implementation).
>>>>>>>> But for now I'll need the key for FFDHE.
>>>>>>>
>>>>>>> Do I understand you correctly that the dhchap_key is used as the
>>>>>>> input
>>>>>>> to
>>>>>>> the 
>>>>>>> DH - i.e. it is the remote public key then? It looks strange that
>>>>>>> this
>>>>>>> is
>>>>>>> used 
>>>>>>> for DH but then it is changed here by hashing it together with
>>>>>>> something
>>>>>>> else 
>>>>>>> to form a new dhchap_key. Maybe that is what the protocol says.
>>>>>>> But it
>>>>>>> sounds 
>>>>>>> strange to me, especially when you think that dhchap_key would be,
>>>>>>> say,
>>>>>>> 2048 
>>>>>>> bits if it is truly the remote public key and then after the
>>>>>>> hashing
>>>>>>> it is
>>>>>>> 256 
>>>>>>> this dhchap_key cannot be used for FFC-DH.
>>>>>>>
>>>>>>> Or are you using the dhchap_key for two different purposes?
>>>>>>>
>>>>>>> It seems I miss something here.
>>>>>>>
>>>>>> No, not entirely. It's me who buggered it up.
>>>>>> I got carried away by the fact that there is a
>>>>>> crypto_dh_encode_key()
>>>>>> function, and thought I need to use it here.
>>>>>
>>>>> Thank you for clarifying that. It sounds to me that there is no
>>>>> defined
>>>>> protocol (or if there, I would be wondering how the code would have
>>>>> worked
>>>>> with a different implementation). Would it make sense to first specify
>>>>> a
>>>>> protocol for authentication and have it discussed? I personally think
>>>>> it
>>>>> is a
>>>>> bit difficult to fully understand the protocol from the code and
>>>>> discuss
>>>>> protocol-level items based on the code.
>>>>>
>>>> Oh, the protocol _is_ specified:
>>>>
>>>>  
>>>> https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2_0-2021.06.02-Ratified-5.pdf
>>>>
>>>> It's just that I have issues translating that spec onto what the kernel
>>>> provides.
>>>
>>> according to the naming conventions there in figures 447 and following:
>>>
>>> - x and y: DH private key (kernel calls it secret set with dh_set_secret
>>> or
>>> encoded into param.key)
>>>
>>
>> But that's were I got confused; one needs a private key here, but there
>> is no obvious candidate for it. But reading it more closely I guess the
>> private key is just a random number (cf the spec: g^y mod p, where y is
>> a random number selected by the host that shall be at least 256 bits
>> long). So I'll fix it up with the next round.
> 
> Here comes the crux: the kernel has an ECC private key generation function
> ecdh_set_secret triggered with crypto_kpp_set_secret using a NULL key, but it
> has no FFC-DH counterpart.
> 
> That said, generating a random number is the most obvious choice, but not the
> right one.
> 
> The correct one would be following SP800-56A rev 3 and here either section
> 5.6.1.1.3 or 5.6.1.1.4.
> 

Oh fsck. Of course. Would've been too easy.
Well, more coding required then. Let's see how it goes.
But thanks for your help!

(And I wouldn't say no if someone would step in an provide a 'real'
FFDHE crypto algorithm; now that the parameters are already present :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare at suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer