Re: [Ace] AD Evaluation of draft-ietf-ace-mqtt-tls-profile-12

Cigdem Sengul <> Fri, 10 December 2021 20:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 662B13A0787; Fri, 10 Dec 2021 12:24:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 VHpVYRsCgGCt; Fri, 10 Dec 2021 12:24:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CB5C3A077D; Fri, 10 Dec 2021 12:24:21 -0800 (PST)
Received: by with SMTP id t13so18814130uad.9; Fri, 10 Dec 2021 12:24:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O0SJ1ZUGr+8Lyyl6iahIEslEnVSW0pXZqCqgM+8QiJ8=; b=jPEYNLP7wyRkPfb/7SrNfYzVAWsN72AhMAO+HvIcqSujPeA2y8k4lsVJUIb5v2uePf NaqxigSQ6GSfrqAK9JJS7HKwokybtzgsoT+00swvm8gLJkQgSETNUWv1vgp/DGS7UBJO oa04KER+AO6t+/foG9FJvKQtKbdJqnT2vPlyjr41P3gyWP2+8xmIIDl36nAlS1NSd1yP 7hBc1FrS1tjlpaDj3sri4J7Ug7ayaf9wmgzkGEzCyp8yJC+QWFyN1bgLtaJy3PzWDqXk 8vV///jlCMyrtnBvllX8jiLQYC61XNwG1lp2ddNMgPOlSC/Au3dA1N6ygEz3f6Tda//6 E5Cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O0SJ1ZUGr+8Lyyl6iahIEslEnVSW0pXZqCqgM+8QiJ8=; b=Zwmk8UworDkZfJS6N7Ppj/Xmz4b1dEAxVvs05akTZNM9xDXRTTt9wIAYDkbkFjG3Ql YPZi0rujVKotS04iPBhpO5NUn0NkibFofMcCMKPwNIhkTJInty427ySy88nH6uBhJZhH yfmclNHXnLLCEASDSwqSvMN3PPPtxB3W7so11KNM6hh04kVVkWfTqbAVlY0UgZ5LeE7l GLo+u/8VhqFX4WbJOVRc5oIQzzOG8mW6uIT3w1kZIZIrc6i7DR7qWW4DQFchtjA0WAkh 2vajKgWcpJW5yWZY0CY3ySnFKpkaOnfG+ziWB22gUAlCaO5YI3A2pibJb6JHRtzz2sRS MPsg==
X-Gm-Message-State: AOAM5324Hr6BXT4lbLM2dFNeEG7ZesT7OtNhlVzXqx4y4qADJn6kSWqE wMN3c+Ycl/mjvJchbe1bo54Y6D8T8Etsl4g+7mHgOJOLIC4=
X-Google-Smtp-Source: ABdhPJwHRKWYxUmdnswgE3yxgJ/pI3OxsOAQj8xQMOi9w6p+5NClJMBijbByIN49e/3TTIBGOhXTh0JLvrv5KYLKVTo=
X-Received: by 2002:ab0:20d4:: with SMTP id z20mr31547014ual.23.1639167858943; Fri, 10 Dec 2021 12:24:18 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Cigdem Sengul <>
Date: Fri, 10 Dec 2021 20:24:07 +0000
Message-ID: <>
To: Benjamin Kaduk <>
Cc:, Ace Wg <>
Content-Type: multipart/alternative; boundary="000000000000f5aaf605d2d081d6"
Archived-At: <>
Subject: Re: [Ace] AD Evaluation of draft-ietf-ace-mqtt-tls-profile-12
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, 10 Dec 2021 20:24:25 -0000

Hello Ben,
No worries. It's been a very busy period for me as well.
My responses are below. Thank you, as always, for your feedback.

On Tue, Dec 7, 2021 at 8:14 PM Benjamin Kaduk <> wrote:

> Hi Cigdem,
> Oof, has it really been two months since you sent this?  I am sorry to have
> let it linger for so long.
> I've gone through the published -13 and have a handful or two of comments
> left (which I will send separately), but let me just reply here to a few
> things first (inline).
> On Mon, Oct 18, 2021 at 03:23:12PM +0100, Cigdem Sengul wrote:
> > Hello Ben,
> > I thought I should comment on your original review to have the same order
> > you initially planned.
> > I went through all the comments, and our discussions of it.
> > The comparison with Editor's copy and github draft is here
> > <
> >
> > .
> >
> > In summary, I made the following changes:
> > (1) Kepts dtls profile informative (going through it, I brought all that
> > applied to this draft but kept out the ones that didn't apply). For
> that, I
> > introduced new sections that explains how we support TLS - PSK and RPK
> for
> > client authentication ( and Aimed to clarify all
> > TLS-related stuff e.g. added recommended references for using TLS in
> > constrained environments, followed the cipher suite requirements from
> these
> > references.
> I think I see what you're trying to do here, and it makes sense in a
> certain way ... but if I go and compare side-by-side the text we have here
> and what's in the DTLS profile, the DTLS profile goes into a lot more
> detail.  In particular, the DTLS profile mentions some things that
> implementations need to do in order to avoid vulnerabilities, and I'm not
> sure that we want to go into so much detail in this document when it's
> already recorded elsewhere.  I'm willing to let the document advance to
> IETF LC and IESG review with this part as-is (but will not be surprised if
> other reviewers raise the topic), but just wanted to check if there's a
> particular reason to want the DTLS profile to not be a normative reference.
> I think I don't understand that part of things very well, so to me there's
> not much harm in making it a normative reference -- maybe I'm missing
> something!

[Cigdem: I wasn't sure if I could make DTLS profile normative when I was
using TLS, and then there were
a few MUSTs in the DTLS profile that I felt didn't apply. But, given there
is a new short draft that says the profile applies to TLS,
things are in a better place (

However, I need input on the following issues before I revise to make DTLS
profile normative, and reorganise the
sections accordingly based on that change i.e., refer more to DTLS sections
in the newly introduced sections,
and shorten them.

The DTLS profile expectedly talks about CoAp, CBOR, COSE (some examples
Also, token expiration is handled differently with MQTT.
Can those be revised for MQTT-TLS profile?
"If the "ace_profile" parameter is present, it is set to "coap_dtls".
"This specification uses CBOR web tokens to convey claims within an access
token issued by the server."
For PSK mode:
"The authorization server adds a "cnf" parameter to the access information
carrying a "COSE_Key" object that informs the client about the shared
secret that is to be used between the client and the resource server. If
the access token carries a symmetric key, the access
   token MUST be encrypted using a "COSE_Encrypt0" structure (see section
7.1 of [RFC8392])."
DTLS channel setup:
 "To do so, it MUST create a "COSE_Key" structure with the "kid" that was
conveyed in the "rs_cnf" claim in the token response from
   the authorization server and the key type "symmetric".
Token expiration:
"As specified in Section 5.10.3 of [I-D.ietf-ace-oauth-authz], the resource
server MUST notify the client with an error response with
   code 4.01 (Unauthorized) for any long running request before terminating
the association."
(The error response for MQTT would be different.)

Also, for PSK,
"If a resource server receives a ClientKeyExchange message that contains a
"psk_identity" with a length greater than zero, it MUST
 parse the contents of the "psk_identity" field as CBOR data structure"
I think this is defined differently in TLS with pre_shared_key extension

> > >
> > >    o  "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT
> > >       message, and MUST be validated using one of the methods described
> > >       in Section 2.2.2.  This option also supports a tokenless
> > >       connection request for AS discovery.
> > >
> > > We should probably look carefully at the "for AS discovery" phrasing,
> in
> > > light of the late changes in how the framework talks about the AS
> > > Request Creation Hints.
> > >
> >
> > [CS: Follows the core document already.]
> I think I wanted to emphasize that this discovery mechanism is
> unauthenticated and that clients need to have some other way to confirm
> that the provided AS URI is authorized to be an AS used by the client.
> I will put some proposed text in my pending PR.

[CS:  I see, I have misunderstood. Thanks.]

> >
> >
> > >
> > >    Section 7.5 of [RFC8446]).  This content is exported from the TLS
> > >    session using the exporter label 'EXPORTER-ACE-MQTT-Sign-Challenge',
> > >    an empty context, and length of 32 bytes.  [...]
> > >
> > > While an empty context should provide ample protection, it seems to me
> > > that we could consider using the client identifier as the context.
> > > There can also be value in incorporating information on the server
> > > identity in the output.  If the SNI extension is used, that information
> > > would already be included in the key schedule, though we do not
> > > currently seem to mandate SNI usage.  Current best practices for new
> > > deployments are to always use SNI and always use ALPN, so we should
> > > probably consider both of those.
> > >
> >
> > [CS: Kept empty context, as the Client Identifier is in the application
> > layer message
> > and not known to the Broker before the TLS handshake. Or I am
> > misunderstanding something.
> Ah, good point about the broker not knowing the client ID at this point.
> So we need to keep the empty context (as you did).

[Cigdem: +1]

> > >
> > > Section 3
> > >
> > >    The scope field contains the publish and subscribe permissions for
> > >    the Client.  The scope is a JSON array, each item following the
> > >    Authorization Information Format (AIF) for ACE [I-D.ietf-ace-aif].
> > >    Using the Concise Data Definition Language (CDDL) [RFC8610], the
> > >    specific data model for MQTT is:
> > >
> > > This seems a little dicey, since we claim to allow JWT tokens as well
> as
> > > CWT.  JWT "scope" is pretty tightly nailed down to be a space-separated
> > > list (though CWT gives much greater freedom).  We probably need to have
> > > some text about this situation, with a phrase about how "in order to be
> > > compatible with the JWT scope format, we use a single scope value with
> > > internal structure", that this structure is also compatible with the
> > > rules, and noting that our AIF usage prevents any internal spaces, so
> > > the interpretation of the scope value is unambiguous even when
> > > unmodified JWT libraries are used.
> > >
> > [In the new section 2.3, this is clarified:
> > "The scope in the token is a single value.  For a JWT, the single
> >    scope has an internal structure of a JSON array, and for a CWT, this
> >    information is represented in CBOR following the Authorization
> >    Information Format (AIF) for ACE [I-D.ietf-ace-aif]."
> I have more to say here but will defer it to my other comments.
[Cigdem: OK. I saw the other comments, will respond separately.]

> Everything else looks great; well done!

[Cigdem: Thank you!]

Kind regards,