On 11/16/21 11:18 AM, Sagi Grimberg wrote:

quoted

quoted

quoted

quoted

quoted

- Transform secret with correct hmac algorithm

Is that what I reported last time? Can you perhaps
point me to the exact patch that fixes this?

Well, no, not really; the patch itself got squashed in the main
patches.
But problem here was that the key transformation from section 8.13.5.7
had been using the hash algorithm from the initial challenge, not the
one specified in the key itself.
This lead to decoding errors when using a key with a different length
than the hash algorithm.

That is exactly what I reported, changing the key length leads to
authentication errors.

Right-o. So it should be sorted then.

Hannes, was the issue on the host side or the controller side?

The issue was actually on the host side.

I'm a little lost into what was the actual fix...

The basic fix was this:

@@ -927,13 +944,17 @@ static int nvme_auth_dhchap_host_response(struct

nvme_ctrl
 *ctrl,

        if (!chap->host_response) {
                chap->host_response =
nvme_auth_transform_key(ctrl->dhchap_key,
-                                       ctrl->dhchap_key_len, chap->hash_id,
+                                       ctrl->dhchap_key_len,
+                                       ctrl->dhchap_key_hash,
                                        ctrl->opts->host->nqn);
                if (IS_ERR(chap->host_response)) {
                        ret = PTR_ERR(chap->host_response);
                        chap->host_response = NULL;
                        return ret;
                }


(minus the linebreaks, of course).
'chap->hash_id' is the hash selected by the initial negotiation, which
is wrong as we should have used the hash function selected by the key
itself.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@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