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

Thank you, Jim, for the comments.
I have created issues corresponding to each one in the GitHub repository.

We will start working on them, and specifically clarify the issues 1-3
around the CONNECT message.

For 4, MQTT v5 can support a challenge-response; not possible with v3
indeed. Will expand the security considerations section on that.

5.  We described a convention in the draft with SHOULD. Do we turn that
into a MUST?

6. We thought that the AS would dictate the token expiration time. It can
also be done that RS times out tokens even if they have not expired. But,
security-performance trade-off should be considered.
Token caching is important even if the token does not need introspection.
The only time the MQTT client can push a token is with the CONNECT message
(all subsequent publish/subscribe messages rely on this). In MQTT v5, a
client can push a new token via reauthentication during an ongoing session
(enabled by MQTT v5). If RS times out the token, this means a disconnection
in MQTT v3. We mention this  in Security considerations as "it is expected
that AS follows a reasonable expiration strategy for access tokens"

-->There may be workarounds designed especially MQTT v5 which has better
support for request-response style communication. But need to think about
it.

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
>