Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nvme-cli is overly restrictive on permitted key lengths for various hash functions #1669

Open
martin-gpy opened this issue Sep 7, 2022 · 3 comments

Comments

@martin-gpy
Copy link
Contributor

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.

@igaw
Copy link
Collaborator

igaw commented Sep 30, 2022

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

image

Why should allow anything else except 32, 48 or 64 key length when there is no matching hash function identifier?

@martin-gpy
Copy link
Contributor Author

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:

Screenshot - Recommendation for Key Management Part 1 - General - NIST SP 800-57pt1r5 pdf

@igaw
Copy link
Collaborator

igaw commented Oct 13, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants