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

Cigdem Sengul <> Tue, 21 May 2019 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A44AC1200D6; Tue, 21 May 2019 13:35:18 -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 hoSq3fv6-jPW; Tue, 21 May 2019 13:35:15 -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 7E858120044; Tue, 21 May 2019 13:35:15 -0700 (PDT)
Received: by with SMTP id t1so22131121qtc.12; Tue, 21 May 2019 13:35:15 -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=sf7YDAye5wutsxGwAod+S0Tua9SYitSZeRKF3kb0JeM=; b=Y5fgiMg/QLgodXgkHXEVQTJb1mvDoQKKDld6l0rWio2tbqfI5bIR4UkU2gs6z4gwhI ukO+jQHUQeRpjhBq4VGm30+jx5N2W+y32sOpnJd4ZqH/AyMekJNLG4FRbE+CHCXpppta VMKw/02Mj1hI6+eLln7vJCULiVCcJQSvcQOM90Q9ne6FRtmyYt987RELlEn7BdQuA4gT nB0/T+I3gIYs0OWUd5d9okF1127VI57KfnKFWU4pQPiKlxwYDkubLjeZNE8pbtUDirOS 2uSdjjRLGmlWDwRnJdQ4l+nBWnK8h3lvb7kzUr/40F3O+XoOs4Q08VvjCuRrlguhIkjX S7PA==
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=sf7YDAye5wutsxGwAod+S0Tua9SYitSZeRKF3kb0JeM=; b=KKhHKT8oFLGzieelrovJIGYZ0yNWeEiJASdcg/L6B+iYWolGy0eH7B9Fih6Gw7h0MN e+EuNxeDWQaZlHjCXy02z68g4GoOv7dh/0pPBC0+0hE19IWxBR6yWAmekx6461lQmgj9 dGzTrTVigT91p84bwvSWXIjZzsJUadEMpTHIn9BMnxrXacb0N8nl4AP4J6cqNc9wF9TJ xo8yR+4Nwd5K8kd/Xt0/A9eJoSvo3LZWxvsimam93eIUa41r+OYS7cYVcssu+JroRgnK lpe5XhGh9MPgoJ2hxHRdYcB6ACRTws8CsoamfdGbOl+rgaqBHL63tkLntEC4P4l/g0Ix MLCw==
X-Gm-Message-State: APjAAAUTPZfcIxI8izkkP2TZ8vt3rR/J3m2+4T/WkaXQnNTwJyxFCMdT bo8vZ02xa0a+SuAyvJcJPyYhGmU/hIavyL7HjfE=
X-Google-Smtp-Source: APXvYqwTUhMz41h8pxNLQG1UFdgFt+Lu5WNwh6hAU+GQ+yVVPJAC58vYZD7cDFTODxlp4ql90aae/xxvTtxCmbD/SR4=
X-Received: by 2002:a0c:af5c:: with SMTP id j28mr61022707qvc.226.1558470914563; Tue, 21 May 2019 13:35:14 -0700 (PDT)
MIME-Version: 1.0
References: <001901d50e05$74847200$5d8d5600$>
In-Reply-To: <001901d50e05$74847200$5d8d5600$>
From: Cigdem Sengul <>
Date: Tue, 21 May 2019 21:35:03 +0100
Message-ID: <>
To: Jim Schaad <>
Content-Type: multipart/alternative; boundary="00000000000041626205896bc967"
Archived-At: <>
Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile connections
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: Tue, 21 May 2019 20:35:19 -0000

Thank you for your comments.  I see that we tried to cover too many options
in the draft, and things got mixed up. I tried to clarify inline.

* So as a client I get a token from the AS.  For the first run, assume that
> it has a RPK in it.
> * I now connect to the server using TLS.
>         Question #1 - Am I doing client authentication at this point in
> TLS?
> This is what is happening for all of the current profiles, but it is not
> clear that this is happening for this profile.  The answer appears to be
> both yes and no.

The basic method we were thinking:

   1. We have not assumed client-side certificates for authenticating
   clients during TLS handshake. RS uses a server-side certificate.
   2. After the TLS session is set-up, the client passes token and
   authentication data inside the CONNECT message.
   3. RS does proof-of-possession for a key owned by the client - so, RS
   authenticates the token.
   4. From MQTT point of view, the clean session flag in the CONNECT
   indicates, there is no session state. The CONNECT payload includes a Client
   id, this should be sufficiently random (not explained clearly in the
   current draft) and unique across clients.
   5. From ACE point of view, we assumed the client has registered with the
   AS, has established keys; the RS has registered with the AS, has
   established keys. So, using PoP, the RS checks that the client has
   authenticated with AS and was able to acquire a token.

In addition to this,  we state other options in the draft as well: the
client and the RS can use the keys in the token to set-up the TLS session
(then the token is not in CONNECT message, and may need to be pushed via

I checked how client authentication is done in other profiles. I see that
draft-ietf-ace-coap-est has “authentication of the client MUST be with a
client certificate”.  In draft-ietf-ace-oscore-profile/ C-RS authentication
is done implicitly by the possession of a common OSCORE security context.
The latter is closer to what we were trying to achieve.

> * The connect message holds the token and an authentication value.  The
> sentence starting "The client MAY apply ..." in the next to last paragraph
> is totally confusing.  Do I get a choice to create a value or not?  Do I
> get
> a choice as to which method I use (which would seem to be dictated by the
> token type and not by client choice).

That is a mistake - the MAY should have been removed (in an earlier version
of the draft, it stated that “MAY apply it to entire or part of the CONNECT
Indeed the choice of symmetric/asymmetric would depend on the token type.

> * I am flummoxed by the statement that there is sufficient randomness in
> the
> payload when authenticating.  I presume that all that is being used for the
> authentication input is the CONNECT message.  Given that the exact same
> input would be used for two different logons, I do not understand how this
> could be the case.  Impersonation would seem to be an issue in the event
> that the connect message is ever captured (including by the server).  I
> would strongly suggest that there is a requirement to include a value from
> a
> tls-exporter to tie the authentication to a specific session.

It is because we assumed that client ids (23B) in the CONNECT payload would
provide randomness. We do not keep session state (clean session flag is set
across different connects) and hence, there is no incentive for client ids
to be consistent across network sessions. But, you are right, a client may
still repeat client ids across different CONNECTs or it may not select
sufficiently random ids, and an attacker may be able to push the same token
if it was able to capture it.
Will remove the MAY part and add your suggestion to the draft.

> *  Appendix B says that the broker will accept MQTT PUBLISH messages, does
> it have to do a connect before doing the publish or not?  If the connect is
> required then what is used for authentication?
This is the part where we have tried to incorporate autzinfo - taking our
cue from the core draft, we have not assumed that it can be protected - so
no, authentication. Not very comfortable about this - so, open to
suggestions for fixes.

Before publishing or subscribing anything, clients still need to CONNECT.
If they publish to authzinfo - the payload contains a token (as usual
encrypted for RS by the AS). So, I guess, an attacker may try to push a
token that it captured.  But to use it, it will need to disconnect, connect
with TLS, and do PoP.

We definitely need to put more clarifications and fix the randomness issue
in the next iteration.

Please let me know if I have missed or misunderstood something.


> _______________________________________________
> Ace mailing list