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

[Cigdem Sengul <[e-mail]>]

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