From: Vladislav Bolkhovitin <vst@vlnb.net> To: Hannes Reinecke <hare@suse.de>, Sagi Grimberg <sagi@grimberg.me>, Christoph Hellwig <hch@lst.de> Cc: Keith Busch <keith.busch@wdc.com>, linux-nvme@lists.infradead.org, Herbert Xu <herbert@gondor.apana.org.au>, "David S . Miller" <davem@davemloft.net>, linux-crypto@vger.kernel.org Subject: Re: [PATCH 06/11] nvme: Implement In-Band authentication Date: Tue, 20 Jul 2021 23:28:21 +0300 [thread overview] Message-ID: <a3098fb2-2127-6f81-97e9-ab5de503508e@vlnb.net> (raw) In-Reply-To: <d74c29b8-1c64-e439-9015-6c424baad3d3@suse.de> On 7/18/21 3:21 PM, Hannes Reinecke wrote: > On 7/17/21 9:22 AM, Sagi Grimberg wrote: >>> Implement NVMe-oF In-Band authentication. This patch adds two new >>> fabric options 'dhchap_key' to specify the PSK >> >> pre-shared-key. >> >> Also, we need a sysfs knob to rotate the key that will trigger >> re-authentication or even a simple controller(s-plural) reset, so this >> should go beyond just the connection string. >> > > Yeah, re-authentication currently is not implemented. I first wanted to > get this patchset out such that we can settle on the userspace interface > (both from host and target). > I'll have to think on how we should handle authentication; one of the > really interesting cases would be when one malicious admin will _just_ > send a 'negotiate' command to the controller. As per spec the controller > will be waiting for an 'authentication receive' command to send a > 'challenge' payload back to the host. But that will never come, so as it > stands currently the controller is required to abort the connection. > Not very nice. Yes, in this case after some reasonable timeout (I would suggest 10-15 seconds) the controller expected to abort connection and clean up all allocated resources. To handle DoS possibility to make too many such "orphan" negotiations, hence consume all controller memory, some additional handling is needed. For simplicity as a first step I would suggest to have a global limit on number of currently being authenticated connections. [...] >>> + chap->key = nvme_auth_extract_secret(ctrl->opts->dhchap_secret, >>> + &chap->key_len); >>> + if (IS_ERR(chap->key)) { >>> + ret = PTR_ERR(chap->key); >>> + chap->key = NULL; >>> + return ret; >>> + } >>> + >>> + if (key_hash == 0) >>> + return 0; >>> + >>> + hmac_name = nvme_auth_hmac_name(key_hash); >>> + if (!hmac_name) { >>> + pr_debug("Invalid key hash id %d\n", key_hash); >>> + return -EKEYREJECTED; >>> + } >> >> Why does the user influence the hmac used? isn't that is driven >> by the susbsystem? >> >> I don't think that the user should choose in this level. >> > > That is another weirdness of the spec. > The _secret_ will be hashed with a specific function, and that function > is stated in the transport representation. > (Cf section "DH-HMAC-CHAP Security Requirements"). > This is _not_ the hash function used by the authentication itself, which > will be selected by the protocol. > So it's not the user here, but rather the transport specification of the > key which selects the hash algorithm. Yes, good catch. It looks as a minor errata material to specify that hash function here is implementation specific. I would suggest to just hardcode SHA512 here. Users don't have to be confused by this. Vlad
WARNING: multiple messages have this Message-ID (diff)
From: Vladislav Bolkhovitin <vst@vlnb.net> To: Hannes Reinecke <hare@suse.de>, Sagi Grimberg <sagi@grimberg.me>, Christoph Hellwig <hch@lst.de> Cc: Keith Busch <keith.busch@wdc.com>, linux-nvme@lists.infradead.org, Herbert Xu <herbert@gondor.apana.org.au>, "David S . Miller" <davem@davemloft.net>, linux-crypto@vger.kernel.org Subject: Re: [PATCH 06/11] nvme: Implement In-Band authentication Date: Tue, 20 Jul 2021 23:28:21 +0300 [thread overview] Message-ID: <a3098fb2-2127-6f81-97e9-ab5de503508e@vlnb.net> (raw) In-Reply-To: <d74c29b8-1c64-e439-9015-6c424baad3d3@suse.de> On 7/18/21 3:21 PM, Hannes Reinecke wrote: > On 7/17/21 9:22 AM, Sagi Grimberg wrote: >>> Implement NVMe-oF In-Band authentication. This patch adds two new >>> fabric options 'dhchap_key' to specify the PSK >> >> pre-shared-key. >> >> Also, we need a sysfs knob to rotate the key that will trigger >> re-authentication or even a simple controller(s-plural) reset, so this >> should go beyond just the connection string. >> > > Yeah, re-authentication currently is not implemented. I first wanted to > get this patchset out such that we can settle on the userspace interface > (both from host and target). > I'll have to think on how we should handle authentication; one of the > really interesting cases would be when one malicious admin will _just_ > send a 'negotiate' command to the controller. As per spec the controller > will be waiting for an 'authentication receive' command to send a > 'challenge' payload back to the host. But that will never come, so as it > stands currently the controller is required to abort the connection. > Not very nice. Yes, in this case after some reasonable timeout (I would suggest 10-15 seconds) the controller expected to abort connection and clean up all allocated resources. To handle DoS possibility to make too many such "orphan" negotiations, hence consume all controller memory, some additional handling is needed. For simplicity as a first step I would suggest to have a global limit on number of currently being authenticated connections. [...] >>> + chap->key = nvme_auth_extract_secret(ctrl->opts->dhchap_secret, >>> + &chap->key_len); >>> + if (IS_ERR(chap->key)) { >>> + ret = PTR_ERR(chap->key); >>> + chap->key = NULL; >>> + return ret; >>> + } >>> + >>> + if (key_hash == 0) >>> + return 0; >>> + >>> + hmac_name = nvme_auth_hmac_name(key_hash); >>> + if (!hmac_name) { >>> + pr_debug("Invalid key hash id %d\n", key_hash); >>> + return -EKEYREJECTED; >>> + } >> >> Why does the user influence the hmac used? isn't that is driven >> by the susbsystem? >> >> I don't think that the user should choose in this level. >> > > That is another weirdness of the spec. > The _secret_ will be hashed with a specific function, and that function > is stated in the transport representation. > (Cf section "DH-HMAC-CHAP Security Requirements"). > This is _not_ the hash function used by the authentication itself, which > will be selected by the protocol. > So it's not the user here, but rather the transport specification of the > key which selects the hash algorithm. Yes, good catch. It looks as a minor errata material to specify that hash function here is implementation specific. I would suggest to just hardcode SHA512 here. Users don't have to be confused by this. Vlad _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-07-20 20:50 UTC|newest] Thread overview: 179+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-16 11:04 [RFC PATCH 00/11] nvme: In-band authentication support Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 01/11] crypto: add crypto_has_shash() Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:08 ` Sagi Grimberg 2021-07-17 6:08 ` Sagi Grimberg 2021-07-16 11:04 ` [PATCH 02/11] crypto: add crypto_has_kpp() Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:08 ` Sagi Grimberg 2021-07-17 6:08 ` Sagi Grimberg 2021-07-16 11:04 ` [PATCH 03/11] crypto/ffdhe: Finite Field DH Ephemeral Parameters Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:14 ` Sagi Grimberg 2021-07-17 6:14 ` Sagi Grimberg 2021-07-17 13:57 ` Hannes Reinecke 2021-07-17 13:57 ` Hannes Reinecke 2021-07-17 15:03 ` Stephan Müller 2021-07-17 15:03 ` Stephan Müller 2021-07-18 12:22 ` Hannes Reinecke 2021-07-18 12:22 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 04/11] lib/base64: RFC4648-compliant base64 encoding Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:16 ` Sagi Grimberg 2021-07-17 6:16 ` Sagi Grimberg 2021-07-17 14:00 ` Hannes Reinecke 2021-07-17 14:00 ` Hannes Reinecke 2021-07-17 14:12 ` Eric Biggers 2021-07-17 14:12 ` Eric Biggers 2021-07-17 14:20 ` Eric Biggers 2021-07-17 14:20 ` Eric Biggers 2021-07-16 11:04 ` [PATCH 05/11] nvme: add definitions for NVMe In-Band authentication Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:30 ` Sagi Grimberg 2021-07-17 6:30 ` Sagi Grimberg 2021-07-17 14:04 ` Hannes Reinecke 2021-07-17 14:04 ` Hannes Reinecke 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-16 11:04 ` [PATCH 06/11] nvme: Implement " Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 7:22 ` Sagi Grimberg 2021-07-17 7:22 ` Sagi Grimberg 2021-07-18 12:21 ` Hannes Reinecke 2021-07-18 12:21 ` Hannes Reinecke 2021-07-19 8:47 ` Sagi Grimberg 2021-07-19 8:47 ` Sagi Grimberg 2021-07-20 20:28 ` Vladislav Bolkhovitin [this message] 2021-07-20 20:28 ` Vladislav Bolkhovitin 2021-07-21 6:12 ` Hannes Reinecke 2021-07-21 6:12 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:43 ` Hannes Reinecke 2021-07-18 12:43 ` Hannes Reinecke 2021-07-18 12:47 ` Stephan Müller 2021-07-18 12:47 ` Stephan Müller 2021-07-20 20:27 ` Vladislav Bolkhovitin 2021-07-20 20:27 ` Vladislav Bolkhovitin 2021-07-21 6:08 ` Hannes Reinecke 2021-07-21 6:08 ` Hannes Reinecke 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-16 11:04 ` [PATCH 07/11] nvme-auth: augmented challenge support Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:27 ` Hannes Reinecke 2021-07-18 12:27 ` Hannes Reinecke 2021-07-18 12:57 ` Stephan Müller 2021-07-18 12:57 ` Stephan Müller 2021-07-19 9:21 ` Sagi Grimberg 2021-07-19 9:21 ` Sagi Grimberg 2021-07-20 13:12 ` Hannes Reinecke 2021-07-20 13:12 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 08/11] nvmet: Parse fabrics commands on all queues Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-19 9:21 ` Sagi Grimberg 2021-07-19 9:21 ` Sagi Grimberg 2021-07-16 11:04 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:37 ` Hannes Reinecke 2021-07-18 12:37 ` Hannes Reinecke 2021-07-18 12:56 ` Stephan Müller 2021-07-18 12:56 ` Stephan Müller 2021-07-19 8:15 ` Hannes Reinecke 2021-07-19 8:15 ` Hannes Reinecke 2021-07-19 8:51 ` Stephan Mueller 2021-07-19 8:51 ` Stephan Mueller 2021-07-19 9:57 ` Hannes Reinecke 2021-07-19 9:57 ` Hannes Reinecke 2021-07-19 10:19 ` Stephan Mueller 2021-07-19 10:19 ` Stephan Mueller 2021-07-19 11:10 ` Hannes Reinecke 2021-07-19 11:10 ` Hannes Reinecke 2021-07-19 11:52 ` Stephan Mueller 2021-07-19 11:52 ` Stephan Mueller 2021-07-19 12:08 ` Hannes Reinecke 2021-07-19 12:08 ` Hannes Reinecke 2021-07-20 10:14 ` Hannes Reinecke 2021-07-20 10:14 ` Hannes Reinecke 2021-07-20 10:49 ` Simo Sorce 2021-07-20 10:49 ` Simo Sorce 2021-07-20 11:31 ` Hannes Reinecke 2021-07-20 11:31 ` Hannes Reinecke 2021-07-20 14:44 ` Simo Sorce 2021-07-20 14:44 ` Simo Sorce 2021-07-20 14:47 ` Stephan Mueller 2021-07-20 14:47 ` Stephan Mueller 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-18 13:26 ` Herbert Xu 2021-07-18 13:26 ` Herbert Xu 2021-07-19 20:38 ` Sagi Grimberg 2021-07-19 20:38 ` Sagi Grimberg 2021-07-20 6:08 ` Hannes Reinecke 2021-07-20 6:08 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 10/11] nvmet-auth: implement support for augmented challenge Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:25 ` Hannes Reinecke 2021-07-18 12:25 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 11/11] nvme: add non-standard ECDH and curve25517 algorithms Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 16:50 ` Stephan Müller 2021-07-17 16:50 ` Stephan Müller 2021-07-18 12:44 ` Hannes Reinecke 2021-07-18 12:44 ` Hannes Reinecke 2021-07-19 9:23 ` Sagi Grimberg 2021-07-19 9:23 ` Sagi Grimberg 2021-07-19 9:56 ` Hannes Reinecke 2021-07-19 9:56 ` Hannes Reinecke 2021-07-17 6:06 ` [RFC PATCH 00/11] nvme: In-band authentication support Sagi Grimberg 2021-07-17 6:06 ` Sagi Grimberg 2021-07-19 10:02 ` Simo Sorce 2021-07-19 10:02 ` Simo Sorce 2021-07-19 11:11 ` Hannes Reinecke 2021-07-19 11:11 ` Hannes Reinecke 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-21 6:06 ` Hannes Reinecke 2021-07-21 6:06 ` Hannes Reinecke 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-24 11:17 ` Hannes Reinecke 2021-07-24 11:17 ` Hannes Reinecke 2022-03-23 7:12 [PATCHv9 " Hannes Reinecke 2022-03-23 7:12 ` [PATCH 06/11] nvme: Implement In-Band authentication Hannes Reinecke 2022-03-24 16:53 ` Chaitanya Kulkarni 2022-03-25 7:57 ` Hannes Reinecke 2022-03-28 8:08 [PATCHv10 00/11] nvme: In-band authentication support Hannes Reinecke 2022-03-28 8:08 ` [PATCH 06/11] nvme: Implement In-Band authentication Hannes Reinecke 2022-03-28 13:39 [PATCHv11 00/11] nvme: In-band authentication support Hannes Reinecke 2022-03-28 13:39 ` [PATCH 06/11] nvme: Implement In-Band authentication Hannes Reinecke 2022-04-27 17:59 ` Nayak, Prashanth 2022-04-28 6:05 ` Hannes Reinecke 2022-05-18 11:22 [PATCHv12 00/11] nvme: In-band authentication support Hannes Reinecke 2022-05-18 11:22 ` [PATCH 06/11] nvme: Implement In-Band authentication Hannes Reinecke 2022-06-08 14:45 [PATCHv14 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-08 14:45 ` [PATCH 06/11] nvme: Implement In-Band authentication Hannes Reinecke 2022-06-13 18:12 ` Christoph Hellwig 2022-06-20 6:50 ` Hannes Reinecke 2022-06-21 9:02 [PATCHv15 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-21 9:02 ` [PATCH 06/11] nvme: Implement In-Band authentication Hannes Reinecke 2022-06-21 14:24 ` Sagi Grimberg 2022-06-21 14:26 ` Hannes Reinecke 2022-06-21 14:50 ` Sagi Grimberg 2022-06-21 14:59 ` Sagi Grimberg 2022-06-22 6:01 ` Hannes Reinecke 2022-06-22 8:43 ` Sagi Grimberg 2022-06-22 9:06 ` Hannes Reinecke 2022-06-22 9:09 ` Sagi Grimberg 2022-06-22 9:20 ` Hannes Reinecke 2022-06-22 9:58 ` Sagi Grimberg 2022-06-22 10:26 ` Hannes Reinecke 2022-06-22 10:31 ` Sagi Grimberg 2022-06-22 5:43 ` Hannes Reinecke 2022-06-21 17:24 [PATCHv16 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-21 17:24 ` [PATCH 06/11] nvme: Implement In-Band authentication Hannes Reinecke 2022-06-22 17:43 ` Sagi Grimberg 2022-06-23 6:17 [PATCHv17 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-23 6:17 ` [PATCH 06/11] nvme: Implement In-Band authentication Hannes Reinecke 2022-06-27 9:51 [PATCHv18 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-27 9:52 ` [PATCH 06/11] nvme: Implement In-Band authentication Hannes Reinecke
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=a3098fb2-2127-6f81-97e9-ab5de503508e@vlnb.net \ --to=vst@vlnb.net \ --cc=davem@davemloft.net \ --cc=hare@suse.de \ --cc=hch@lst.de \ --cc=herbert@gondor.apana.org.au \ --cc=keith.busch@wdc.com \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=sagi@grimberg.me \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.