Hi Cigdem, This works for me. Thanks for the responses.
Yours, Daniel ________________________________ From: Ace <[email protected]> on behalf of Cigdem Sengul <[email protected]> Sent: Wednesday, September 23, 2020 9:10 AM To: Daniel Migault <[email protected]> Cc: Ace Wg <[email protected]> Subject: Re: [Ace] WGLC draft-ietf-ace-mqtt-tls-profile Hello Daniel, My responses are as follows: <mglt> Just one clarification. TLS 1.3 provides two ways to authenticate the client. One way is sending a certificaterequest during the TLS handshake and another way is to send it after the handshake occurs. The ability to support the first authentication is not advertised by the TLS client. The ability to support the second is advertised with the post_handshake_auth extension. I just wanted to make sure we agreed there are two ways. </mglt> [Cigdem: Yes, I agree. In both cases, what I read is: "If the client does not send any certificates (i.e., it sends an empty Certificate message), the server MAY at its discretion either continue the handshake without client authentication or abort the handshake with a "certificate_required" alert." I suggest continue the handshake and fallback to MQTT Connect authentication for the RPK case. ] [Cigdem : Yes, actually, this is what I described above. Due to absence of a certificate, I suggest it can fall back to CONNECT] <mglt> You are correct. What might need to be specified is that the server MUST support the two ways to authenticate the client. It MUST try during the handshake and if the client as not provided the sufficient credentials and the client has the post_handshake_auth, it MUST send one after the hanshake. The reason I think that maybe more text is needed is that I have the impression a minimal TLS server implementation may not necessary support both authentications. This would prevent the use of an TLS implementation that only supports post_authentication for example. Similarly, I am wondering if the MQTT client does not have similar requirements regarding the support of TLS authentication as well as the CONNECT or if it may support only one. I tend to think that the client may only support only one way. To sum up, I am just trying to evaluate how to prevent a situation where the client will not be abel to authenticate itself to the server. </mglt> [Cigdem: I think what I would prefer is that: the MQTT client will support one way (one of PSK, or RPK, or over MQTT Connect then). The server MAY support multiple ways. Given we recommend the MQTT Connect for client authentication, the server MUST implement that. (That's why if RPK fails, MQTT connect can be fallback.) If we agree, I will revise the document. ] Kind regards, --Cigdem
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
