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

[Stephan Mueller]

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)

- g^x mod p  / g^y mod p: DH public keys from either end that is communicated
over the wire (corresponding to the the DH private keys of x and y) - to set
it, you initialize a dh request and set the public key to it with
kpp_request_set_input. After performing the crypto_kpp_compute_shared_secret
you receive the shared secret

- g^xy mod p: DH shared secret - this is the one that is to be used for the
subsequent hashing /HMAC operations as this is the one that is identical on
both, the host and the controller.

Ciao
Stephan