On 11/16/21 11:18 AM, Sagi Grimberg wrote:
>
>>>>>> - 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@xxxxxxx +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
