search

ace-wg / mqtt-tls-profile

Document for MQTT-TLS-profile
Other
0 stars 2 forks source link

Reorganise 2.1.2 #29

Closed ciseng closed 4 years ago

ciseng commented 5 years ago

. It might make sense to break up section 2.1.2 more and cover the different methods either in continuous paragraphs or in subsections.

Sure. That would increase readability. It became rather long with the new additions.

ciseng commented 5 years ago

Daniel Migault's comment:

It would be good to expand Raw Public Keys (RPK). My reading is that this section does not provide a single mechanism for the Client to be authenticated by the Broker, but instead two different ways. I would thus recommend to state it clearly in the introduction of the section.. Currently, the section mentions: """ This section describes how the Client transports the token to the    Broker (RS) via the CONNECT control message after the TLS handshake. """

An then we have a relatively detailed description on how this is performed using TLS. It might be better to say something around the following lines: """ This section describes how the Client transports the token to the    Broker (RS). This can be achieved during the TLS KEX or during the MQTT session establishment via the CONNECT control message after the TLS handshake. """

I am not sure that MAY is appropriated here. I suspect that if none are supported, this method will not work. As a result, if seems to me that it woudl be more accurate to say that TLS Client and TLS server MUST support the PSK authentication as well as the raw public key.

One issue I have with I-D.gerdes-ace-dtls-authorize that is now draft-ietf-ace-dtls-authorize is that it seems to only consider TLS 1.2. With TLS 1.3 PSK and RPK are supported.

My interpretation is that PSK provides mutual authentication, but in our case RPK will only authenticate the client. If that is correct, there might be a new to specify how the RS is authenticated by the Client.

jimsch commented 5 years ago

Both PSK and RPK are defined for TLS 1.2 as well. The only reason why draft-ietf-ace-dtls-authorize does not reference TLS 1.3 is because DTLS 1.3 has not yet been completed. I would not consider that to be a difference.

I agree the PSK provides mutual authentication. The question of RPK giving mutual authentication depends on which RPK you are talking about. This is just like the question of using certificates and if you have mutual authentication there. There is also not a requirement that you use RPK in both directions. One could do a certificate for the server and an RPK for the client and that would give you mutual authentication.

ciseng commented 5 years ago

The section organisation has been changed, and all options for client and server authentication are added.