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

Daniel Migault <daniel.migault@ericsson.com> Thu, 25 July 2019 15:33 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E885512021D; Thu, 25 Jul 2019 08:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.557
X-Spam-Level:
X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rh3sagvKpm2; Thu, 25 Jul 2019 08:32:58 -0700 (PDT)
Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473F31201BB; Thu, 25 Jul 2019 08:32:58 -0700 (PDT)
Received: by mail-vs1-f42.google.com with SMTP id 2so33943355vso.8; Thu, 25 Jul 2019 08:32:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nm1sPFyQxyBTarslFzWImtjpfeVV/lLwAIv3IbdNRIA=; b=kAbjrGQ+yFqTb0krCvbeUdCUrgRi+dYjr5pBVZkGInAb9BwB9I1pO44GHEUBedeceI pO1x4hQ8zHgVQQ+9lv/a8uFQkrgyQaHE87RieG2R4LsS9F7k2eujc2019t6FpvrqS5uM dOMNBXII+/FUboya2jPxgWG/A+naZbqKj1MPofI1k1ITrEK8PiG8D+XV5JK7mNN42ALQ dO6nPHbkny8ZypSZiQhPeP+dfBRo/9yIprplQw/iGhrMxcOU7VFP0wvoPQZNu53oOSaj jXkLluiqzXTl+Iz76vEqzpk24m9knE8wehQaIe0aUwqXFd8kMz/dB2JeENE6GlVLWyTS Ag9g==
X-Gm-Message-State: APjAAAWkFmUo6ce/lO8JuQI4hWjA0r+SmadB4YrvLiPFqyqcp9vbc/7p SH8libVoHly6xwhlcnDk7lvsxOhlqZ3eSEpSn/mw7A==
X-Google-Smtp-Source: APXvYqyzeWa421Ovdt7//+2jLCJ0eX9RG4Z6GCvpTY1M7pyRTJfUoJYouUtXDvu0qVPsksOzNWXsyqD3oHzwwtD9f4E=
X-Received: by 2002:a67:e90c:: with SMTP id c12mr11606358vso.97.1564068776944; Thu, 25 Jul 2019 08:32:56 -0700 (PDT)
MIME-Version: 1.0
References: <009c01d510e9$7eada030$7c08e090$@augustcellars.com> <CAA7SwCP3soOFTfKOHPAXo3eur0VrgHG81c++c=ipNKOYL2Mu6g@mail.gmail.com> <001001d5118e$aa155290$fe3ff7b0$@augustcellars.com> <CAA7SwCPc3qM0DjX76ZJ2EWDUt1_FUE+zbQoADY+fyAZoHH0vZg@mail.gmail.com> <CADZyTk=x1BEk47uozNdiFmntiHY+VypGV18HropS0pgT++ZabQ@mail.gmail.com> <CAA7SwCN-GZJKER6tun+D4pem50Om+0=SLBu-M0=9unFWBCz4iw@mail.gmail.com>
In-Reply-To: <CAA7SwCN-GZJKER6tun+D4pem50Om+0=SLBu-M0=9unFWBCz4iw@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Thu, 25 Jul 2019 11:32:45 -0400
Message-ID: <CADZyTkkHKU01Nd4tGsXXPNe_reWoXY8PDPWJzAFmovmQ7SpK7g@mail.gmail.com>
To: Cigdem Sengul <cigdem.sengul@gmail.com>
Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Jim Schaad <ietf@augustcellars.com>, ace@ietf.org
Content-Type: multipart/alternative; boundary="000000000000daa9fa058e8323ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/-lEDS0LRKwvTJNGwElcbVRQOHpY>
Subject: Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 15:33:03 -0000

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