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

Cigdem Sengul <> Thu, 23 May 2019 11:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCF0C1200C7; Thu, 23 May 2019 04:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b2PZePyOT_1y; Thu, 23 May 2019 04:20:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E487120019; Thu, 23 May 2019 04:20:52 -0700 (PDT)
Received: by with SMTP id t1so6180989qtc.12; Thu, 23 May 2019 04:20:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=geK7DfoAj9IPFDHqca07qRAv6f7QZuy6GQLiTaNktvQ=; b=lUqm72IdVBLeJ8DG4ylhYJg0ie3WI+c8jNCaCj7YXUsTaGvQVseRSawY6HWz+Io8YQ 74YJAUFUgr+Ed5hsAKAtX6arDlHJPxEHQ9ceXJPPq8Rdvqp8q2SjJ21DXx+Jb0MgknB3 DnJvolPtIzlhR3L2NlyNuqcbPan5mMoKgT6QrJcm87F5PKyhtjm1eRFoAyu3yvFIx8ua Knc3ORoxBzw5t/osI6iM1MFuSSPsEuWu+UuB0fxJRd3h9W8GyoGYviULir4C6bTlMyFW hLp+MfXkapJ9Qdpg4wqf3HUf8LB0JwMOI13m/UBtCk5lymQvZnMNTsdtJeYvvdAiNWai oUFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=geK7DfoAj9IPFDHqca07qRAv6f7QZuy6GQLiTaNktvQ=; b=nB2231nzDCB/IHUCxmeiKHgFzkqNo5BEKQhUtaiGU52b0KZPuCUebV+WmVEpl67JMo KtzKdKXRo0d5zaZelQEM5uWWIAoNrrfrhji7hBRXMl5HIjsjA7mMtsGw7DE48E1Hqc5R Knc2HJeAoyCqePqYu1hI6GtFLkCkJdAIWFSQ1X1gHjLtnMzLZ60q6e+DOracOgbyF1mO YH+5d6f1Qs1dMj+YESMTbvxuVOqTCYmyMKTrrCBU6rySfqJEq0QF0qG/O2aVDfoQ238Z doLPuup3g0kZgptYOjVDJqXchMG5mL7X9UP8FT9sFSU5jxaf61UssfmCqBFm/UfiuR0t EpiA==
X-Gm-Message-State: APjAAAU0QGk63fZm29RNl32v1zpxUt4WAiKKYdUtJIuxMyiaYxENs+lt uJzqWqPKhXNdXg1qRbOSTFz3Qn39a0m2Pkb+fZG7ehaZvNw=
X-Google-Smtp-Source: APXvYqyZ3TDGEET7kBaPN8Lcv8QnHwNaS50eA5hBM4SWJkh9qzRGXOFVDbRLD0t7+ziKRpBKs1QxuQ/eb8IuVKFV7sA=
X-Received: by 2002:ac8:2f98:: with SMTP id l24mr45762559qta.78.1558610451216; Thu, 23 May 2019 04:20:51 -0700 (PDT)
MIME-Version: 1.0
References: <009c01d510e9$7eada030$7c08e090$>
In-Reply-To: <009c01d510e9$7eada030$7c08e090$>
From: Cigdem Sengul <>
Date: Thu, 23 May 2019 12:20:40 +0100
Message-ID: <>
To: Jim Schaad <>
Content-Type: multipart/alternative; boundary="00000000000049bcdb05898c46ca"
Archived-At: <>
Subject: Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 May 2019 11:20:55 -0000

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

7. That is correct. Will add the clarification.


On Wed, May 22, 2019 at 10:58 PM Jim Schaad <>; 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