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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/ace >>>> >>>> _______________________________________________ >>> Ace mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ace >>> >> _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
