Hello Andrei - > On Mar 2, 2023, at 12:47 PM, Andrei Popov <andrei.po...@microsoft.com> wrote: > >> I don't have details, but the NVMe/TCP specification suggests that it can >> make use of multiple PSK identities during a TLS handshake. > From my read of NVMe spec, it's one PSK/identity per TLS connection: > > "8.13.5.9 Generated PSK for TLS > When used with a non-NULL DH exchange, the DH-HMAC-CHAP protocol is able to > generate a session > key KS used to generate *a pre-shared key (PSK)* to establish a secure > channel session with the TLS protocol > between host and controller. A TLS session is concatenated to an > authentication transaction when the > SC_C indication is set to 01h in the AUTH_Negotiate message. A TLS session > should not be concatenated > to an authentication transaction if the involved host and controller are > administratively configured with *a > PSK* for use with each other. In this case, host and controller should just > establish a TLS session based on > the configured PSK." > > From the above, it looks like NVMe specifies two options: > 1. Generating PSK based on a Diffie-Hellman key exchange (as part of > DH-HMAC-CHAP protocol). > 2. Admin configuring host and controller with a PSK. > In both cases, it seems that there is one PSK/identity per host-controller > connection. > > Please correct me if I mis-interpret the NVMe spec,
This is what I've been told: NVMe-TCP spec v1.0a section 3.6.1.3 (TLS PSK and PSK Identity Derivation): > In TLS 1.3 each PSK is identified by the client using a PSK > identity. Each PSK is also associated with one hash function > that shall be the same as the hash function of the selected > ciphersuite. For example, the cipher suites TLS_AES_128_GCM_SHA256 > and TLS_AES_256_GCM_SHA384 use the SHA-256 and SHA-384 hash > functions respectively. A TLS client that offers both cipher > suites shall offer two PSKs with different identities, different > hash functions, and different key material. In addition to that, each cipher suite might be used for either generated or retained PSKs. This results in a total of 4 possible PSK identities, each with different keying material. As per TLS 1.3 it's then the servers responsibility to pick one of the presented identities, and return that one with the ServerHello response. The PSK of the returned identity will then be used for the connection. Thus there is only one PSK/identity per connection. It's only the ClientHello which can/might carry several PSK identities (as outlined in RFC 8446). Note also: there is a provision in the NVMe spec to send only a single PSK identity with ClientHello: > A TLS 1.3 client implementation that only supports sending > a single PSK identity during connection setup may be required > to connect multiple times in order to negotiate cipher suites > with different hash functions. -- Chuck Lever _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
