Hi Cigdem, Thanks for the resposnes. Please find my comments inline.
Yours, Daniel On Tue, Sep 22, 2020 at 4:37 PM Cigdem Sengul <[email protected]> wrote: > Dear Daniel, > > Thank you very much for the responses. Mine are inline as well. > Kind regards, > --Cigdem > > > > On Mon, Sep 21, 2020 at 4:06 PM Daniel Migault <[email protected]> > wrote: > >> Hi Cigdem, >> >> Please find my quick answer. Note these answers/comments are based on >> your response and what I remember from the document. That should be >> sufficient to clear most of them. I preferred to post the response earlier. >> >> Yours, >> Daniel >> >> On Sat, Sep 19, 2020 at 11:05 AM Cigdem Sengul <[email protected]> >> wrote: >> >>> >>>> >>>> 2.2. Client Connection Request to the Broker (C) >>>> >>>> 2.2.1. Client-Server Authentication over TLS and MQTT >>>> >>>> >>>> It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace. >>>> >>>> The Broker MUST be authenticated during the TLS handshake. If the >>>> Client authentication uses TLS:Known(RPK/PSK), then the Broker is >>>> authenticated using the respective method. Otherwise, to >>>> authenticate the Broker, the client MUST validate a public key from a >>>> X.509 certificate or an RPK from the Broker against the 'rs_cnf' >>>> parameter in the token response. The AS MAY include the thumbprint >>>> of the RS's X.509 certificate in the 'rs_cnf' (thumbprint as defined >>>> in [I-D.ietf-cose-x509]). In this case, the client MUST validate the >>>> RS certificate against this thumbprint. >>>> >>>> <mglt> >>>> >>>> I am considering two main ways to >>>> authenticate the client >>>> TLS:Anon-MQTT:ace and >>>> TLS:Known(RPK/PSK)-MQTT:none. If a >>>> server supports both it is unclear >>>> to me how he can distinguish one >>>> method of authentication versus the >>>> other. >>>> >>>> TLS:Known(PSK)-MQTT:none If the TLS >>>> client provides a psk_identity, the >>>> TLS server may take this as an >>>> indication and lookup in the >>>> authz-info to see if there is a >>>> matching identity. This would >>>> assume that that kid is mentioned >>>> in the PoP. >>>> >>>> TLS:Known(RPSK)-MQTT:none If the >>>> client provides a >>>> post_handshake_auth, this may be >>>> taken as a hint that the client is >>>> associated to a RPSK. The Broker >>>> may instead chose to send a >>>> CertificateRequest, and upon >>>> receiving the Certificate message >>>> verify there is a matching RPK. If >>>> the client does not provide the >>>> post_handshake_auth, it is unclear >>>> to me how the broker may >>>> distinguish a >>>> TLS:Known(RPSK)-MQTT:none from a >>>> TLS:Anon-MQTT:ace. >>>> >>>> In case there is no matching RPK, I >>>> am wondering if the broker falls >>>> back in a expected >>>> TLS:Anon-MQTT:ace. >>>> >>>> I might be missing something, but >>>> it seems that the authentication >>>> method is pre-agreed. Maybe some >>>> text may be added here. >>>> >>>> </mglt> >>>> >>> >>> [Cigdem: Yes, I assumed the flow you mentioned: >>> If the client is using PSK to authenticate then, I assume Client Hello >>> includes pre_shared_key (as described in RFC 8446: 2.2. Resumption and >>> Pre-Shared Key (PSK)). >>> For clients that want to do RPK, I assumed they will do >>> "post_handshake_auth" >>> and the server will do a CertificateRequest, but if the client declines >>> or fails to authenticate, will expect authentication over MQTT:ace. >>> >> <mglt> >> Unless I am missing something in TLS 1.3 or in ACE. The client can >> authenticate with a Post Handshake Client Authentication or during the TLS >> base handshake (appendix E.1.2). In the second case , I do not see any >> specific extensions that the client provides to indicate it supports the >> client authentication during the handshake. It seems the server logic that >> decides to send a CertificateRequest >> </mglt> >> > > [Cigdem: TLS 1.3: > ""When the client has sent the “post_handshake_auth” extension (see > Section 4.2.6), a server MAY request client authentication > at any time after the handshake has completed by sending a > CertificateRequest message. The client MUST respond with the > appropriate Authentication messages (see Section 4.4). If the client > chooses to authenticate, it MUST send Certificate, > CertificateVerify, and Finished. If it declines, it MUST send a > Certificate message containing no certificates followed by > Finished." > > So, my understanding the client may not authenticate during > post_handshake_auth. Cllient authentication over TLS can be configured > optional at the server, and the server can tolerate an empty certificate > list. In this case, I assumed that the server checks the client > verification result and falls back to authenticating via MQTT connect. > > Again, if any of the handshake fails - PSK/RPK aborts (different than > empty certificate list), authentication fails. > ] > <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> > > >> >>> If the client TLS handshake includes PSK/RPK authentication information, >>> then the AS will look for whether a token has been submitted via authz-info. >>> >>> Next, after processing the MQTT CONNECT message, it finds another token, >>> then it overwrites all the permissions set-up in TLS handshake. >>> >>> I can add: "If the client fails to authenticate over TLS, the AS falls >>> back to TLS:Anon-MQTT:ace." >>> >>> Would that be more clear? >>> >> <mglt> >> This means that MQTT server will send a CertificateRequest, If an empty >> Certificate is received from the client and the client has provided a >> post_handshake extension, the MQTT server will try a post handshake >> exchange. >> In both cases, the client authentication may fail because the server is >> unable to verify the signature or because no signature is provided. If the >> signature fails, TLS exchange is aborted. So MQTT authentication is only >> considered if the client has not been authenticated via TLS due to the >> absence of a signature. In this case, it will use ace authentication during >> the CONNECT message. >> > > [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> > >> If TLS client is authenticated, the MQTT server will look for at >> authz_info right after the TLS exchange. Then looking at the CONNECT. >> > > [Cigdem: If TLS client managed to authenticate, then the MQTT server may > have already used what was submitted through authz_info. > i.e., if it is through RPK, it would assume to find it mathching rpk bound > to the pre-submitted token via authz-info.] > > <mglt>I think we agree.</mglt> > > >> >> Am I correct ? >> >> I think that originally, my comment was here as I expected that a >> server could support a single mode, but it seems the MQTT server needs to >> support all modes. Correct ? If so, maybe that could be clarified as well >> as the specific logic of the server. >> >> </mglt> >> > > [Cigdem: I assumed some flexibility, i.e PSK or RPK; if client does not > submit an RPK, fall back to CONNECT. > If this is not acceptable, I can clarify more strictly a single mode] > <mglt> So just re-stating my previous comment. I think we may rovide some text so minimal or restricted implementations of MQTT / TLS guarantee the interoperability between client and server. </mglt> > >>>> 3.1. PUBLISH Messages from the Publisher Client to the Broker >>>> >>>> >>>> If the Client is allowed to publish to the topic, the Broker must >>>> >>>> <mglt> >>>> >>>> I have the impression MUST would be >>>> acceptable too. I am not saying >>>> "must" is not acceptable but I >>>> would like we check this is not a >>>> mistake. >>>> >>>> </mglt> >>>> >>> >>> [Cigdem: I think I should add an explanation that if the requirement >>> comes from MQTT standart, the draft uses "must". >>> All the musts for the profile are MUST. >>> ] >>> >> <mglt> >> So must has also a different meaning than MUST in IETF language. So all >> must cannot be given that meaning. I suspect that either we put MUST or add >> an explanation line that clarify the meaning (origin) of the must. >> </mglt> >> > [Cigdem: This seems to be creating a confusion with others too. Then I > remove must/should etc. language, and just say: "If the client is allowed > to publish to the topic, the RS publishes the message to all valid > subscribers of the topic."] > <mglt> looks clearer to me as well. </mglt> -- Daniel Migault Ericsson
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
