Re: [Ace] WGLC draft-ietf-ace-mqtt-tls-profile

[Daniel Migault <[e-mail]>]

Hi Cigdem,

This works for me. Thanks for the responses.

Yours, Daniel
________________________________
From: Ace <[e-mail]> on behalf of Cigdem Sengul <[e-mail]>
Sent: Wednesday, September 23, 2020 9:10 AM
To: Daniel Migault <[e-mail]>
Cc: Ace Wg <[e-mail]>
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