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

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 <cigdem.sengul@gmail.com>
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 <ietf@augustcellars.com>
>>> 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
>>> Ace@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>>> _______________________________________________
>> Ace mailing list
>> Ace@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace
>>
>