Open martin-gpy opened 2 years ago
8.13.5.1` Protocol Operations
For an NVM subsystem, the controller is the entity running the protocol, using the identity and credentials
of the NVM subsystem. The DH-HMAC-CHAP protocol proceeds in the following order:
1. [...] For DH-HMAC-CHAP, the authentication protocol descriptor includes the list of hash functions (HashIDList) and Diffie-
Hellman group identifiers (DHgIDList) that may be used in this authentication protocol transaction
Why should allow anything else except 32, 48 or 64 key length when there is no matching hash function identifier?
Well, Table 3 of the NIST SP 800-57 Part-1 shows 128/192/256 bits, although there are other dependencies shown in that table:
Again, there are no identifier in the current nvme spec defined for different key lengths. Any upcoming changes in the spec can't be implemented until the relevant document has been publicly released.
Looks like the latest nvme-cli is overly restrictive in terms of permitted key lengths for the various hash functions used in NVMe in-band auth. For e.g. it currently enforces a strict key length of 32, 48 & 64 for the SHA-256, SHA-384 & SHA-512 hash functions respectively.
As per NIST SP 800-57, there is a lot more room for flexibility in this area. For e.g. a key length of 32 bytes should probably be acceptable for SHA-384 & SHA-512 hash functions as well.