Subject: [Ace] Comments on draft-sengul-ace-mqtt-tls-profile-00

From: Paul Fremantle <[email-masked]>
Date: Thu, 8 Jun 2017 11:14:13 +0100

Hi

I would like to make some comments on the
draft draft-sengul-ace-mqtt-tls-profile-00.

Since this is my first post to the group, let me briefly introduce myself.
I have previously sat on the MQTT TC at OASIS and I also have participated
in the W3C and OASIS before. I haven't yet done anything at the IETF, so I
realise that I have to learn a different approach, which I'm looking
forward to.

I also am the lead author on one a paper that is cited by the draft [1].
Since then I have extended the flows around MQTT and OAuth2 to include use
of the Authorization Code flow and Refresh Flow, which are documented in
[2] and also available in an open source repository in Github [3]. My
approach so far has used Bearer tokens, not PoP tokens, so the cited work
is not directly applicable to the proposal, but I believe may have some
useful input. There is also another paper on the subject at [5].

1) I think this proposal is really useful and welcome.

2) I'd like to make an overall comment regarding the MQTT specification.
The current standard (v3.1.1) is widely adopted and used, and will likely
remain so for a while still. However, there are issues in using it with
OAuth2, especially around request-response flows. These issues seem to be
resolved in the proposed working draft [4] for MQTT 5.0 (the replacement
version). Therefore it would seem like a good idea for this proposed
mapping of ACE to MQTT to look at the current 3.1.1 and proposed 5.0
versions as two different approaches, where it might be positive to
postpone certain aspects into the 5.0 approach that are hard to deal with
in 3.1.1. I will call these out below.

3) I'd be interested to know why the specification calls out the Will
message handling, as it seems that it proposes the normal MQTT behaviour.
Maybe I misunderstood?

4) The proposal to allow clients to include the token in the payload of
publish messages (2.2.1) seems to me to be challenging. The problem is that
MQTT 3.1.1 has no way of adding headers to the message, so I can understand
that this is a way around this. However, I feel that this mixes up the
layering of the protocol. This is one area where MQTT 5.0 will solve a
problem (with MQTT Properties, and the ability to reauthenticate), so I
would suggest considering that this be removed and dealt with in a MQTT 5.0
specific way.

5) There is some description of how the server should acknowledge messages
in 2.2.1. Again, as in point 3, if there is no change to the default
behaviour of MQTT then it maybe better not to call it out in this
specification.

6) In 2.2.2, the specification calls out the behaviour of the broker
onbound, once a publish message is received. This seems to imply that all
the publishers and subscribers to a broker are using ACE. Is that an
assumption of this spec or can it support both ACE and non-ACE systems. For
example, an ACE-based publisher and a subscriber that uses a traditional
MQTT authorisation scheme? Since the authorisation of subscribers using ACE
is covered in 2.3, maybe it is not necessary to have 2.2.2 at all

7) The approach proposed in  Appendix B seems to enable DoS attacks against
the broker. It is not clear to me on reading this what the benefits are,
but that is probably my lack of knowledge of the ACE approach. Can someone
please help me understand the purpose of this flow.

8) Appendix C seems to be trying to deal with the situation where a
client's token has expired but it may carry on working with reduced
permissions and this will be signalled with a special message to a system
topic. This seems overly complex to put in the specification. Again, this
will be resolved with MQTT 5.0 where the broker will be able to request the
client to re-authenticate without dropping the connection, and also will be
able to drop the connection more gracefully. Looking at this from a client
device development perspective, it seems that there are two options:
a) Build a client that can cope with listening for "downgrade" messages and
that can cope with downgraded permissions when tokens expire
b) Build a client that can cope with abrupt disconnections, and can deal
with expired tokens.
Since clients already have to have logic to handle (b) anyway, the value of
(a) seems less.

9) I hope this hasn't come across as overly negative. There is a lot I like
about this specification but I felt that a detailed set of comments would
be useful to the authors. Also I may well have misunderstood aspects of
this spec!

10) I'd be very interested in adding support for flows that are currently
out of band in this spec. At the moment, as I understand it, a device would
need to support HTTPS or another protocol to interact with the AS. In [2] I
have mapped the token flows, refresh flows etc into MQTT and it might be
useful to standardise these. Let me know if that is of interest.

Thanks
Paul

[1] Fremantle, Paul, et al. "Federated identity and access management for
the internet of things." *Secure Internet of Things (SIoT), 2014
International Workshop on*. IEEE, 2014.

[2] Fremantle, Paul, and Benjamin Aziz. "OAuthing: privacy-enhancing
federation for the Internet of Things." (2016).

[3] https://github.com/pzfreo/oauthing

[4] MQTT v5.0 Working Draft 13:
https://www.oasis-open.org/committees/download.php/60716/mqtt-v5.0-wd13.pdf

[5] Fremantle, Paul, Jacek Kopecký, and Benjamin Aziz. "Web api management
meets the internet of things." *European Semantic Web Conference*. Springer
International Publishing, 2015.

-- 
Paul Fremantle
Doctoral Researcher, University of Portsmouth, School of Computing
Visiting Scientist, Institute of the Architecture of Application Systems,
Stuttgart
Visiting Lecturer, Software Engineering Programme, Oxford University
Co-Founder, WSO2
Apache Member and Committer
email: [email-masked], [email-masked]
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 8 Jun 2017 14:43:38 +0200

Hello Paul,

although I'm not one of the authors of this draft, I feel I can help 
with the two questions concerning appendices B and C. Please find my 
comments inline. Feel free to ask for further clarifications.

/Ludwig

> draft draft-sengul-ace-mqtt-tls-profile-00.
...
> 7) The approach proposed in  Appendix B seems to enable DoS attacks 
> against the broker. It is not clear to me on reading this what the 
> benefits are, but that is probably my lack of knowledge of the ACE 
> approach. Can someone please help me understand the purpose of this flow.
As you described in 4), sending the token in the payload of MQTT 
messages is challenging. Therefore Appendix B describes a way to submit 
tokens to the broker previous to requests (both publish and subscribe).

Obviously you can overload the broker with fake access tokens using the 
authz-info topic, but since all clients (both publishers and 
subscribers) will be unauthorized before they first transmit their 
access token (in whatever way they do that), the broker has to make a 
leap of faith to accept data that might potentially be an access token 
in some way. I don't see this way as being more dangerous than any other 
method of initially providing an access token to the broker.

This flow is analogous to what the ACE framework defines, i.e. an 
unprotected REST resource "authz-info" to which client can POST their 
access tokens.

> permissions and this will be signalled with a special message to a 
> system topic. 

I think there is a slight misunderstanding in the second part of that 
sentence. Appendix C deals with the situation where a client's token has 
either expired or otherwise become invalid and the broker whishes to 
inform the client of this situation. I was told that there is currently 
no message defined in MQTT for signaling a broker side disconnect to the 
client. This was created as a workaround to that problem.
Furthermore the proposal in Appendix C deals with cases where a client 
has a successful connection and a valid token, but whishes to submit an 
additional token granting further access rights.

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Cigdem Sengul <[email-masked]>
Date: Thu, 8 Jun 2017 13:48:56 +0100

Thanks Paul, I will be responding to your comments soon (away from my desk
at rsac unplugged today :) )

And thanks Ludwig, for offering clarifications.
Later,
--Cigdem

On Thursday, June 8, 2017, Ludwig Seitz <[email-masked]> wrote:

> Hello Paul,
>
> although I'm not one of the authors of this draft, I feel I can help with
> the two questions concerning appendices B and C. Please find my comments
> inline. Feel free to ask for further clarifications.
>
> /Ludwig
>
>> I would like to make some comments on the draft
>> draft-sengul-ace-mqtt-tls-profile-00.
>>
>> ...
>
>> against the broker. It is not clear to me on reading this what the benefits
>> are, but that is probably my lack of knowledge of the ACE approach. Can
>> someone please help me understand the purpose of this flow.
>>
> As you described in 4), sending the token in the payload of MQTT messages
> is challenging. Therefore Appendix B describes a way to submit tokens to
> the broker previous to requests (both publish and subscribe).
>
> authz-info topic, but since all clients (both publishers and subscribers)
> will be unauthorized before they first transmit their access token (in
> whatever way they do that), the broker has to make a leap of faith to
> accept data that might potentially be an access token in some way. I don't
> see this way as being more dangerous than any other method of initially
> providing an access token to the broker.
>
>> topic.
> either expired or otherwise become invalid and the broker whishes to inform
> the client of this situation. I was told that there is currently no message
> defined in MQTT for signaling a broker side disconnect to the client. This
> was created as a workaround to that problem.
> Furthermore the proposal in Appendix C deals with cases where a client has
> a successful connection and a valid token, but whishes to submit an
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Paul Fremantle <[email-masked]>
Date: Thu, 8 Jun 2017 13:53:07 +0100

Ludwig

Thanks very much for the quick response and the useful info.

For the first issue, I can see that there is an analogous model to the ACE
approach on CoAP. I guess there is a difference with MQTT. In MQTT, for the
client to publish to an unsecured topic, they need to CONNECT with no
credentials, which many MQTT users would not like. While a DoS attacker
could make many CONNECT messages with incorrect credentials, this is
something that is already expected from the MQTT server's perspective, and
the server can disconnect the connection quickly. In the case where a DoS
attacker can connect without credentials, they can simply leave the
connection open without publishing, or attempt to publish to other topics,
etc, whereby they can use a lot more resources on the server than if they
simply try a bad CONNECT packet. This is because of the connection-oriented
model of MQTT.

As for the second point, I now understand it much better. I will need to
think about this in more detail.

Best
Paul

---

From: Cigdem Sengul <[email-masked]>
Date: Fri, 9 Jun 2017 16:56:21 +0100

Hello Paul,
Again, thank you very much for your comments.
We would be very happy to work with you on this draft.  We can try together
to incorporate some of  your suggestions and your OAuth/MQTT work into the
draft.

Answers are below for the rest of your comments.

> in 3.1.1. I will call these out below.

Indeed. We were aware of the work on MQTT version 5.0 when we set out
to  write the draft. But, we did not know when it would be approved. So, we
decided to base the work on the official standard. But, we hinted in the
draft that some of the implementation difficulties can be ironed out with
the new version of MQTT.
Once the new version becomes official, it would be useful to update the
spec to cover both versions.

> message handling, as it seems that it proposes the normal MQTT behaviour.

In our draft, we included all  the MQTT messages that would be affected by
an authorisation decision. This was to make sure we do not leave any gaps,
when the MQTT v3.1 is considered. Also, in our draft, the broker triggers
server disconnects due to authorisation problems. Hence, we are creating a
condition where a WILL message would be appropriate (the WILL message
should be sent of course only if the client specified it in the CONNECT).

> would suggest considering that this be removed and dealt with in a MQTT 5.0

We were aware this does cross protocol layers, but we wanted an mechanism
for the client to push a new token without disconnecting, reconnecting &
re-subscribing to topics.  It is optional - the fallback would be to
disconnect & reconnect with a new token.  We're open to further feedback
about whether this is a good idea.

> behaviour of MQTT then it maybe better not to call it out in this

Yes, this can be shortened.  We can just say: "the broker behaves according
to the MQTT spec and may or may not send an ACK depending on the QoS
level". We wish to still keep some information for the broker response for
completeness sake.

> is covered in 2.3, maybe it is not necessary to have 2.2.2 at all

We thought about the possibility of supporting ACE & non-ACE clients.  This
is an interesting idea: would allow us  to support legacy clients.
But, in a mixed scenario, the broker then also needs an authorisation
function, e.g. using ACLs, separately from the authorisation server.
This is to make sure that only “authorised” clients publish/subscribe to
“protected” topics.
The draft doesn't exclude this possibility.

It's worth including 2.2.2 for clarity, to explain how the broker forwards
the PUBLISH messages to clients, and specifically the behaviour on token
expiry.  We'll try to make it more concise.

> someone please help me understand the purpose of this flow.

This, as stated by Ludwig, was put in to support /authz-info of ACE.  It
was to support the PoP keys to be used in TLS handshake between the client
 and the broker.  But yes, the MQTT server needs to be resistant to DoS
attempts pre-authorisation. MQTT needs to resist DoS before and during
CONNECT (TCP holding, excess data). MQTT with /authz-info needs to
implement similar resistance, for example dropping connections that fail to
authenticate in a timely fashion, and blocking repeated offenders, so
there's little difference in theory - although resistance pre-CONNECT may
already exist in some broker implementations.  A discussion can be put in
Security Considerations.

> a) Build a client that can cope with listening for "downgrade" messages
> and that can cope with downgraded permissions when tokens expire
> Since clients already have to have logic to handle (b) anyway, the value
> of (a) seems less.
>
>
Indeed, this section was put in for better error handling. Some of these
issues may be resolved with the new MQTT v5.0.
The option of feeding new tokens can  be handled here - but, again the
reauthentication approach may help with this issue in MQTT v5. We need to
check MQTT v5 and think a bit more on this.
We need to clarify the draft so that this section is described  more
clearly (also to include some of the points Ludwig raised).

> be useful to the authors. Also I may well have misunderstood aspects of
Not at all, we wholeheartedly appreciate the response & opportunity for
discussion!

Thanks,
Cigdem and Anthony

---

From: Paul Fremantle <[email-masked]>
Date: Sun, 11 Jun 2017 07:04:35 +0100

Cigdem and Anthony

Thanks for the feedback.

> to incorporate some of  your suggestions and your OAuth/MQTT work into the

I'd be very happy to collaborate.

> spec to cover both versions.

That seems like a great approach. I'd be happy to help with this.

> In our draft, we included all  the MQTT messages that would be affected
> by an authorisation decision. This was to make sure we do not leave any
> gaps, when the MQTT v3.1 is considered. Also, in our draft, the broker
> triggers server disconnects due to authorisation problems. Hence, we are
> creating a condition where a WILL message would be appropriate (the WILL
> message should be sent of course only if the client specified it in the
> CONNECT).
>

I see. I think this is a good idea, but I think it would be useful to state
that this is the default MQTT behaviour and that this spec is not
overriding it.

> about whether this is a good idea.

I would be interested to hear what others think. My own experience of MQTT
and other pub/sub systems would make me believe we would be better to
support this in MQTT 5, but not in MQTT 3. I understand that it is
optional, but in general I feel that constrained choices are better in
constrained device scenarios.

>
>
>> 5) There is some description of how the server should acknowledge
>> messages in 2.2.1. Again, as in point 3, if there is no change to the
>> default behaviour of MQTT then it maybe better not to call it out in this
>> specification.
>>
>
> Yes, this can be shortened.  We can just say: "the broker behaves
> according to the MQTT spec and may or may not send an ACK depending on the
> QoS level". We wish to still keep some information for the broker response
> for completeness sake.
>

Sounds good.

> We thought about the possibility of supporting ACE & non-ACE clients.
> This is an interesting idea: would allow us  to support legacy clients.

> expiry.  We'll try to make it more concise.

Couldn't we point to the next section and say that "when the subscriber is
also using this profile, the broker then behaves as in 2.2.3" or something
similar? I agree that dealing with token expiry is important.

> Security Considerations

I agree that a discussion of the pros and cons of this approach would be
valuable. I'm not clear on the benefits of using POP keys in TLS
handshakes. Can you please point me where to look?

> clearly (also to include some of the points Ludwig raised).

I'm still not clear that it isn't simpler and more effective to force the
client to reconnect. In MQTT clients and servers are expected to be able to
deal with unannounced disconnects. For example, many people use MQTT over
3G connections or other unreliable connections.

Thanks for the feedback. Let me know how I can best join in the
contribution.

Best
Paul

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 12 Jun 2017 07:46:42 +0200

On 2017-06-11 08:04, Paul Fremantle wrote:
~snip~
>     This, as stated by Ludwig, was put in to support /authz-info of
>     ACE.  It was to support the PoP keys to be used in TLS handshake
>     between the client  and the broker.  But yes, the MQTT server needs
>     to be resistant to DoS attempts pre-authorisation. MQTT needs to
>     resist DoS before and during CONNECT (TCP holding, excess data).
>     MQTT with /authz-info needs to implement similar resistance, for
>     example dropping connections that fail to authenticate in a timely
>     fashion, and blocking repeated offenders, so there's little
>     difference in theory - although resistance pre-CONNECT may already
>     exist in some broker implementations.  A discussion can be put in
>     Security Considerations
> 
> 

The idea is to use the key used in the TLS handshake (e.g. the 
pre-shared key when an RFC 4279 handshake is used or the raw public key 
for a RFC 7250 handshake) as the POP key.
This way the TLS handshake provides the proof of possession (for 
asymmetric keys you need to require client authentication).

Have a look at 
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-07 for 
more background on PoP.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Paul Fremantle <[email-masked]>
Date: Mon, 12 Jun 2017 07:29:35 +0100

Thanks Ludwig.

Paul

On 12 Jun 2017 6:46 am, "Ludwig Seitz" <[email-masked]> wrote:

> The idea is to use the key used in the TLS handshake (e.g. the pre-shared
> key when an RFC 4279 handshake is used or the raw public key for a RFC 7250
> handshake) as the POP key.
> Have a look at https://tools.ietf.org/html/dr
> aft-ietf-oauth-pop-architecture-07 for more background on PoP.
>
> /Ludwig
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE SICS
> Phone +46(0)70-349 92 51
>