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

[Daniel Migault <[e-mail]>]

looks fine to me, thanks for addressing them. Let the WG know when you have
a stable version, so that further reviews can be provided.

Yours,
Daniel

On Thu, Jul 25, 2019 at 10:54 AM Cigdem Sengul <[e-mail]>
wrote:

> Hello Daniel,
>
> Thank you very much for your comments. I have commented on them below and
> created corresponding GitHub issues to be addressed soon.
>
> One thing that affects how we address most of the comments is the order of
> presentation of MQTT v5 and MQTT v3.1.1.
> I completely agree that if the order is reversed, and v3.1.1. 1 is
> presented for backward compatibility, this would improve the document.
> This is the highest priority issue, and all the other issues will be
> addressed once that change is made.
>
> Other comments and pointers to Github are inline. Let me know if I missed
> anything.
>
> Sincerely,
> --Cigdem
>
> ...
>>    improvements to the basic protocol with the new MQTT v5.0 - the OASIS
>>    Standard [MQTT-OASIS-Standard-v5] (e.g., improved authentication
>>    exchange and error reporting).  Both versions are expected to be
>>    supported in practice, and therefore, covered in this document.
>>
>> <mglt>
>>
>> I understand that the basic protocol refers to MQTTv3.3.1.1 It might be
>> clearer to explicitly mention that MQTT v3.1.1 is the basic protocol.
>> The other way around could be to remove to the basis protocol" in the
>> latest sentence.
>>
>> Probably that my missing background on MQTT, but -at least for my
>> personnal knowledge - I believe that some clarification over the support
>> of the v5 and v3.1.1 could be clarified.  When support for both version
>> is mentioned, I am wondering if this documents mandate that any RS
>> implements both v3.1.1 AND v5 or if it states that v3.1.1 is by no way
>> being sunset. In other words, it is envisioned that some system will use
>> v3.1.1 *for ever* in which case their associated is expected to support
>> v3.1.1. The same will occur for v5 respectively. Another alternative
>> could be that MQTTv5 adds functionalities to v3.1.1, leading to some
>> sort of backward compatibility that are sufficient in most cases.
>>
>> </mglt>
>>
>
> Cigdem:
> This would be somewhat clarified when we present MQTT v5 first and
> recommend its use.
> https://github.com/ace-wg/mqtt-tls-profile/issues/12
>
> Everything that is described for MQTT v3.1. is doable by MQTT v5, and
> therefore there is backward compatibility.
> However, it has to be signalled to the client indeed.
>
> The broker should advertise which version(s) it supports.
>
> https://github.com/ace-wg/mqtt-tls-profile/issues/9
>
>
>
>>
>>
>>    Clients use client authorization servers [I-D.ietf-ace-actors] to
>>    obtain tokens from the authorization server.  The communication
>>    protocol between the client authorization server and the
>>    authorization server is assumed to be HTTPS.  Also, if the broker
>>    supports token introspection, it is assumed to use HTTPS to
>>    communicate with the authorization server.  These interfaces MAY be
>>    implemented using other protocols, e.g., CoAP or MQTT.
>>
>> <mglt>
>> I have the impression that the proposed alternatives are unsecured. I am
>> wondering if that is intentional. I believe that these communications
>> needs to be secured appropriately.
>>
>> My understanding is that MQTT will work on top of TCP/TLS. If that is
>> correct, I am wondering if it is envisioned that a full HTTP client is
>> embedded into small motes, or a minimal library restricted to support
>> the interaction with the AS. The reason I am asking this question is
>> related to a discussion we had in homenet, so that is only for my
>> personal knowledge and unrelated to MQTT.
>>
>> </mglt>
>>
>
> Cigdem:
>
>  The resource-constrained client needs to support MQTT and ACE only.
>
> The client authorisation server (CAS) and resource broker (server)  (RS)
> need to support HTTPS - they may want to communicate over MQTT or CoAP but
> these need to be secured as expected from CAS-AS and RS-AS security
> requirements of ACE core document.
>
> You have a later comment on this, which I respond to there but it will be
> tied to the same Github issue.
>
> Created GitHub issue: https://github.com/ace-wg/mqtt-tls-profile/issues/10
>
>>
>>
>>    The term "Resource" is used to refer to an MQTT "topic name," which
>>    is defined in Section 1.3.  Hence, the "Resource Owner" is any entity
>>    that can authoritatively speak for the "topic".
>>
>> <mglt>
>> scetion 1.3 defines the Topic name. It might be more helpful to the
>> reader if the exact same term is used both in the text of the document
>> and in the terminology - that is even considering upper/lower letters.
>>
>> I am wondering if broker should be defined as well.
>>
>> Similarly, there seems that Clients are composed of various sub clients
>> ( client authorisation server, client (MQTT), subscriber, publisher).
>> Maybe these different designation could be defined as well in the
>> terminology section. Maybe also some designations might not be necessary
>> to introduce.
>> </mglt>
>>
>
> Cigdem:
>
> Will make sure consistency in upper/lower characters.
>
> Will define the broker.
>
>
> Yes, we assumed there may be a CAS that will speak HTTPS to get the tokens
> from AS. Or if the client itself is capable of doing that, it would not
> need a CAS.
>
>
> Other than that, the MQTT client software may act both as a publisher or
> subscriber. We only separated them for the clarity of presentation.
>
> Also, there are some command line MQTT clients that just publish or just
> subscribe.
>
> Still, I would not consider publisher/subscriber pieces as sub-clients.  I
> think we explain this in the text but will also bring it to the Terminology
> section.
>
> Github issue: https://github.com/ace-wg/mqtt-tls-profile/issues/11
>
>>
>>
>>
>>    Subscription
>>            A subscription comprises a Topic filter and a maximum quality
>>            of service (QoS).
>> <mglt>
>> I am wondering why the subscription does not consider the identity(ies),
>> location(s) of the subscriber(s). I the reason that this parameters are
>> define over an established session, which in the case of MQTT is
>> TCP/TLS. I also suspect there is a MQTT session handling subscribers,
>> publisher connectivity.
>>
>> </mglt>
>>
>
> Cigdem :
>
> This is the standard definition in MQTT. We have not modified this.
>
> MQTT broker maintains connections to all clients; there is a way to keep
> alive. The CONNECT message establishes the session.
>
>>
>>
>> 2.1.1.  Client Authorization Server (CAS) and Authorization Server (AS)
>>         Interaction
>>
>>    The first step in the protocol flow (Figure 1 (A)) is the token
>>    acquisition by the client authorization server (CAS) from the AS.  If
>>    a client has enough resources and can support HTTPS, or optionally
>>    the AS supports MQTTS, these steps can instead be carried out by a
>>    client directly.
>>
>> <mglt>
>> MQTTS and CAS should in my opinion be mentioned in the terminology
>> section.
>>
>> "optionally" might be clarified further. The introduction mentioned
>> HTTPS was considered as the supported protocol. but it seems here that
>> the support of HTTPS may not be obvious, in which case the support of
>> MQTTS might be RECOMMENDED/SHOULD or even stronger.. The recommendation
>> may also be associated to current deployments, especially concerning how
>> AS are dedicated to a technology or not. I do  not see strong
>> recommendations for the AS to support one specific protocol, so I
>> believe clarification/discussions on MQTTS / HTTPS should be provided in
>> the document.
>>
>> """
>>    other underlying
>>    protocols are not prohibited from being supported in the future, such
>>    as HTTP/2, MQTT, BLE and QUIC.
>> """
>>
>> </mglt>
>>
>
> Cigdem:
>
> Will fix. It is RECOMMENDED that HTTPS is used. If AS supports MQTT, MQTTS
> can be used, both this implies a publish/subscribe communication model for
> token issuance. For compatibility with other ASes, this may be left as
> HTTPS.
>
>
> Similarly for token introspection, if MQTTS is used, then it is a
> publish/subscribe communication model.
>
>
> We do not prohibit their use - will add other protocols.
>
> Github issue at https://github.com/ace-wg/mqtt-tls-profile/issues/10
>
>
>> 2.1.2.  Client Connection Request to the Broker
>>
>>    Once the client acquires the token, it can use it to request an MQTT
>>    connection to the broker over a TLS session with server
>>    authentication (Figure 1 (D)).  This section describes the client
>>    transporting the token to the broker (RS) via the CONNECT control
>>    message after the TLS handshake.  This is similar to an earlier
>>    proposal by Fremantle et al. [fremantle14].  An improvement to this
>>    is presented in Section 3 for the MQTT v5 - the OASIS Standard
>>    [MQTT-OASIS-Standard-v5].
>>
>> <mglt>
>> I believe the description of the improvement has been omitted. It woudl
>> help the reader to get an overview of the improvement.
>> </mglt>
>>
>>
> Yes, the improvement is now there are specific fields that can be used for
> authorisation in MQTT v5, and overloading of password/username fields can
> be avoided.
>
> This will be better explained when the order of MQTTv5 and MQTT v3.1.1.1
> is changed.
>
> Github issue at https://github.com/ace-wg/mqtt-tls-profile/issues/12
>
>>
>>
>>    The Will flag indicates that a Will message needs to be sent when a
>>    client disconnection occurs.  The situations in which the Will
>>    message is published include disconnections due to I/O or network
>>    failures, and the server closing the networking connection due to a
>>    protocol error.  The client may set the Will flag as desired (marked
>>    as 'X' in Figure 3).  If the Will flag is set to 1 and the broker
>>    accepts the connection request, the broker must store the Will
>>    message, and publish it when the network connection is closed
>>    according to Will QoS and Will retain parameters, and MQTT Will
>>    management rules.  Section 2.5 explains how the broker deals with the
>>    retained messages in further detail.
>>
>> <mglt>
>> Figure mentions Will Flag while the text mentions Will flag.
>>
>> From the paragraph, I cannot figure out what a Will message is. Maybe
>> that could be explained or a reference to it may be indicated.
>>
>> </mglt>
>>
>
> Cigdem :
>
> Sure, will pay attention to be consistent with the capitalisations.
>
> The Will message is indeed the client’s will when it dies. That’s why it
> is sent in the case of a disconnection. Will improve its explanation.
>
> I can this also to MQTT terminology section:
>
> *Will Message:*
>
> An Application Message which is published by the Server after the Network
> Connection is closed in cases where the Network Connection is not closed
> normally.
>
> If Will Flag is set, then the payload of the Connect message has
> information about the Will message.
>
> The Will Message consists of the Will Properties, Will Topic, and Will
> Payload fields in the CONNECT Payload.
>
> Github issue:https://github.com/ace-wg/mqtt-tls-profile/issues/13
>
> https://github.com/ace-wg/mqtt-tls-profile/issues/11
>
>
>
>>
>>    The broker responses may follow either the MQTT v3.1.1 - the OASIS
>>    Standard [MQTT-OASIS-Standard] or the MQTT v5 - the OASIS Standard
>>    [MQTT-OASIS-Standard-v5], depending on which version(s) the broker
>>    supports.
>> <mglt>
>> I believe that references to MQTTv3.1.1 and MQTTv5 provided in the
>> introduction are sufficient, and there is no need to have teh reference
>> anytime MQTT is invoked.
>> </mglt>
>>
>
> Cigdem:
>
>
> Will remove, and it will improve the readability of the document.
> https://github.com/ace-wg/mqtt-tls-profile/issues/14
>
>
>
>> 3.  Improved Protocol Interactions with MQTT v5
>>
>>    In the new MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5],
>>    several new capabilities are introduced, which enable better
>>    integration with ACE.  The newly enhanced authentication and re-
>>    authentication methods support a wider range of authentication flows
>>    beyond username and password.  With the MQTT v5, there is a clearly
>>    defined approach for using token-based authorization.  Also, it is
>>    possible for a client to request a re-authentication avoiding
>>    disconnection.  Finally, MQTT v5 generally improves error reporting,
>>    enabling better response to authorization failures during publishing
>>    messages to the subscribers.
>>
>> <mglt>
>> Given that MQTT provides a better integration with ACE, I am wondering
>> if MQTTv5 should not be considered as the primary description and having
>> MQTT3.1.1 related to legacy MQTT. This is seems to me simply re-ordering
>> the
>> sections. However, the message carried would be to move to MQTTv5 when
>> possible.
>>
>> I also believe that a recommendation on supporting MQTTv5 should me made
>> in the document.
>>
>> </mglt>
>>
>
> Cigdem:
>
> This is a good idea. We kept the order because of historical reasons. Will
> work on that as a first requirement before fixing other GitHub issues.
> https://github.com/ace-wg/mqtt-tls-profile/issues/12
>
>>
>>   hentication capabilities, it is not necessary to
>>    overload the username and password fields in the CONNECT message for
>>    ACE authentication.  Nevertheless, the RS MUST support both methods
>>    for supporting the token: (1) Token transport via username and
>>    password and (2) using the new AUTH (Authentication Exchange) method.
>>    The token transport via username and password is as described in
>>    Section 2.1.2.  The rest of this section describes the AUTH method.
>>
>> <mglt>
>> As mentioned before, it might be better to mention what to do and
>> explain in MQTT why we overload the username/password.
>> </mglt>
>>
>
>
> Cigdem: If the order of descriptions is changed, then we can clarify this
> better.
>
> Github issue: https://github.com/ace-wg/mqtt-tls-profile/issues/12
>
>
>  On Fri, May 24, 2019 at 4:57 AM Cigdem Sengul <[e-mail]>
> wrote:
>
>> Hello,
>>>
>>> Thanks, Jim, this was helpful, and it also triggered that I go back and
>>> read the introspection section of the core draft again.
>>>
>>>
>>>>
>>>>
>>>> [JLS] For introspection, but not for a published token, the token could
>>>> be “revoked” by the RS.  In this case a new introspection check would lead
>>>> to that information.  There may be ways to deal with this in the
>>>> introspection dialog and not need to be called up here.  The question would
>>>> be does the exi field mean – recheck the token or discard the token.
>>>>
>>>
>>> Understood. We definitely need to clarify here what we do with exi field
>>> if it exists, and if it doesn't exist. The MAY language we used in the
>>> draft is not appropriate if exi does not exist.
>>> We considered the expiration time in the introspection response as a
>>> revocation signal and hence RS discards the token.  (The basic flow was: RS
>>> receives a token, introspects it, caches the result and then when it
>>> expires, it revokes the token - which may next lead to different steps
>>> depending on the version of the MQTT.)
>>> But if introspection is done to handle the case of dynamic authorisation
>>> decisions, and exi would signal a recheck indeed.
>>> Will clarify.
>>>
>>> Thanks,
>>> --Cigdem
>>>
>>>
>>>
>>>>
>>>>
>>>> Jim
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 7. That is correct. Will add the clarification.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> --Cigdem
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, May 22, 2019 at 10:58 PM Jim Schaad <[e-mail]>
>>>> wrote:
>>>>
>>>> Thanks for the updates from my last message.  This has helped quite a
>>>> bit.
>>>>
>>>> 1.  A discussion of the use of raw public keys rather than certificates
>>>> for
>>>> the server may be in order.  This can refer to the same RPK issues from
>>>> the
>>>> current DTLS document.  It may also be that this just uses normal
>>>> certificate processing and that should be noted as well, but some
>>>> discussion
>>>> of deciding if the subject name/alt name matches the token returned
>>>> from the
>>>> AS.
>>>>
>>>> For the connect message there are a couple of issues that need to be
>>>> thought
>>>> about.
>>>>
>>>> 2.  What items are required to be in the connect message.  The response
>>>> to
>>>> my last message suggested that a client identifier is required to be
>>>> present
>>>> but that is not documented.
>>>>
>>>> 3.  It is not completely clear what portions of the CONNECT message are
>>>> being covered by the signature/MAC value.  As an example, is the
>>>> password
>>>> field omitted entirely or is it set to a zero length password.  In
>>>> addition
>>>> to this, from the couple of implementations that I have looked at the
>>>> entire
>>>> packet is not passed out of the base server code for authentication
>>>> purposes.  This might need to be taken into account in terms of what is
>>>> used
>>>> for the body and how it is constructed.  (As a side note, the
>>>> implementations that I have looked at so far also think that the
>>>> password is
>>>> a text string rather than a binary value which is going to be a short
>>>> term
>>>> issue as well.)
>>>>
>>>> 4.  I must admit that I am disappointed that there is no challenge
>>>> response
>>>> mechanism in the MQTT specifications.  I don't know that anything can be
>>>> done at this point about it but there are some security issues that
>>>> need to
>>>> be highlighted because of this in the security considerations section.
>>>> Only
>>>> the v3 seems to have this problem.  Also doing the channel binding would
>>>> deal with this problem as well.  Might just need some general
>>>> discussions
>>>> around the channel binding text.
>>>>
>>>> 5.  Is there an intention to provide a "standard" format for the scope
>>>> field
>>>> or just to leave it as ad hoc?
>>>>
>>>> 6.  It might be reasonable in section 2.1.3 to note that even if a
>>>> result is
>>>> cached, that cached check should be limited for a specific amount of
>>>> time to
>>>> recheck if the token is still active.  More of an issue in terms of how
>>>> long
>>>> to cache for introspection.
>>>>
>>>> 7.  In section 2.1.4 - I would presume that the last paragraph should be
>>>> extended to say that the token is stored only for the length of the
>>>> connection.  That is the token always needs to be supplied every time a
>>>> connect message is sent.
>>>>
>>>> Jim
>>>>
>>>>
>>>> _______________________________________________
>>>> Ace mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ace
>>>>
>>>> _______________________________________________
>>> Ace mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>