> 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, Cheers, Andrei -----Original Message----- From: TLS <[email protected]> On Behalf Of Chuck Lever III Sent: Thursday, March 2, 2023 6:32 AM To: Peter Gutmann <[email protected]> Cc: [email protected] Subject: [EXTERNAL] Re: [TLS] multi-identity support in RFC 8446 [Some people who received this message don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > On Mar 1, 2023, at 11:29 PM, Peter Gutmann <[email protected]> wrote: > > Chuck Lever III <[email protected]> writes: > >> We're implementing TLSv1.3 support for PSK and note there is a >> capability in the PSK extension described in S 4.2.11 for sending a >> list of identities. We don't find support for a list of alternate >> identities implemented in user space TLS libraries such as GnuTLS or >> OpenSSL. Is there a known reason for that omission? > > If it's the same as similar locations in previous versions of TLS > where it's possible to specify a list of X instead of just an X then > it could be because no-one has any idea why you'd specify a list of X, > or what to do with it if one does turn up. There are several fields > where, in the past, we've had users ask what to do with them and it > turned out, after some testing, that the answer is "whatever you want" > because the other side pays no attention whatsoever to what's in there. I don't have details, but the NVMe/TCP specification suggests that it can make use of multiple PSK identities during a TLS handshake. -- Chuck Lever _______________________________________________ TLS mailing list [email protected] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7CAndrei.Popov%40microsoft.com%7Cb6836344b47047a1463508db1b2ae622%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638133643342690211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cksCXJngPspqMYcCmfRTAHwtkRxJ62O50qHTx5gdkgc%3D&reserved=0 _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
