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

[Cigdem Sengul <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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.
]


>
>> 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]


>
> 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.]



>
> 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]

>
>>> 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."]