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

Cigdem Sengul <> Fri, 24 May 2019 08:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E83A212013B; Fri, 24 May 2019 01:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 R0F-x7mILfq8; Fri, 24 May 2019 01:57:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F5F31200EF; Fri, 24 May 2019 01:57:04 -0700 (PDT)
Received: by with SMTP id q197so6318522qke.7; Fri, 24 May 2019 01:57:04 -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=NoQZ/fvm2o0oo0ap7H/QKxjl1+XbJSiMeQV61XIdXC8=; b=Uy2B7TefENpamijaLsiVgv/gR545ztDo8oDqfuh7ILAgRvXPd0KWj1uAXPTbjUjls3 gBp8efr0Qb8YpakC4FDt9icj9wjuINJv1UT2cqfaTJYog+P9NHkspr/S8nG6pRIhUs6u 4ZRnT1gZrvJLC3mmIQbsM1qFQv0dulYolltQCkgc3264bXpOYtqicJRa6eqYH2agssaH 1BtAl6XEH2LXEsCw9vi7Jr0NK+/UQ9q+npF3f+FrB4oxtrOZARxgkvVM8qDb4EmS8D8H pTFQHZQ6G2ebOgmMIVi7bAJZ05uo6QPTAAgdV3fsWhLvlgIzdrcqL2ol1BE23wG/9lIO gmbA==
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=NoQZ/fvm2o0oo0ap7H/QKxjl1+XbJSiMeQV61XIdXC8=; b=eRbT41jYz2kHQMBgPW7SUXRaiYcdPMxMwDFFtfWOMQ1E5EJ++KpEbw/8AVvZ5SDCbD VDUyZ7t8AwSCPVCv5M0Iq/7Y+JW+NXnvqnfn2LiObh2oF57LWGH5jUe83R3R9qrsrt00 oIPnAla5wqxqR7suS/qPqd/L2h38GnJwU3wi3qVgVzBPxTFLfJd6rj57gIHAkGN5i7Io UmsF8q0izmYm6q87Ih6G8S4/PTlsAIOjuHMIND8WWmtuYTrhQmDQmluUujOkiEe2z9yK XFhxpLMCFgMU3bQ66KWmRkJ6Zkd1YTU16bpeUfRbQi3uICOFNg37GdUTwl5el9nEe6R3 TbYw==
X-Gm-Message-State: APjAAAUap8vJtDCJpZcPE3nKIDilEiCi8v4b5Bd3tVjG0ADY6uChUDb0 OyqTU/6exGHw+cEvxJ3dEtWwQOBcCo/xDdsiYtU=
X-Google-Smtp-Source: APXvYqyc7CtV1N+5hobnCPYyTHBXEKigzej1zfa62xry2UuSmZ2XD5KC6p5RTTfffwU3D+8OWb+EyxFp+bJQdc5Yvdg=
X-Received: by 2002:ac8:1c39:: with SMTP id a54mr87043590qtk.344.1558688223790; Fri, 24 May 2019 01:57:03 -0700 (PDT)
MIME-Version: 1.0
References: <009c01d510e9$7eada030$7c08e090$> <> <001001d5118e$aa155290$fe3ff7b0$>
In-Reply-To: <001001d5118e$aa155290$fe3ff7b0$>
From: Cigdem Sengul <>
Date: Fri, 24 May 2019 09:56:52 +0100
Message-ID: <>
To: Jim Schaad <>
Content-Type: multipart/alternative; boundary="000000000000e5099b05899e6133"
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: Fri, 24 May 2019 08:57:07 -0000


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.


> Jim
> 7. That is correct. Will add the clarification.
> Thanks,
> --Cigdem
> 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